Search options (Page 2 of 5)

I must stress I am addressing the situation where sign is the only option chosen -- not sign+encrypt.  If I choose sign only (no encryption), shouldn't it default to clearsign?

As I read the man page:

Sign = Letter signature which may contain binary code
Sign + Ascii = Letter Signature which is purely ascii armored
Clearsign = Append the Signature to the Original letter but keep the contents of the letter legible

So if I just wanted to sign a letter -- but not encrypt it, wouldn't I want to just clearsign the letter?  This would keep the letter readable by those who did not use gpg/pgp.  If Im not mistaken I believe enigmail works this way by clearsigning the document.  I'm asking only for the situation where sign is chosen, not sign+encrypted.  But wouldn't it be possible to clearsign and encrypt too, although I guess it really wouldn't matter in this case. 

From the gpg man pages:
Commands to select the type of operation

     --sign

     -s     Make a signature. This command may be  combined  with  --encrypt
            (for  a signed and encrypted message), --symmetric (for a signed
            and symmetrically encrypted message), or --encrypt and --symmet-
            ric  together  (for a signed message that may be decrypted via a
            secret key or a passphrase).

     --clearsign
            Make a clear text signature. The content in a clear text  signa-
            ture  is readable without any special software. OpenPGP software
            is only needed to verify the signature.  Clear  text  signatures
            may  modify end-of-line whitespace for platform independence and
            are not intended to be reversible.

     --detach-sign

     -b     Make a detached signature.

Wouldn't clear sign be the default preference because in this case only OpenGPG is needed to verify the signature if sign is only chosen as an option?

Can you explain the three parts of the letter specifically with the mechanism currently in place.
The contents of the letter represent = ?
Noname = ?
Encrypted.asc = ?

Should all these parts be appended if I just elect to use sign?

So does Firegpg ignore the possible value of personal-digest-preferences if included in the gpg.conf file?

Probably a valid point on most modern computers, however I'm just saying if you are using a DSA key or DSA2 key there needs to be a distinction.  Only DSA keys can use RIPEMD-160 or SHA1.  DSA2 keys can use all combinations, however you are not gaining anything with SHA512 since the resultant is rounded to 256 bits.  Only RSA keys can take full advantage of SHA512.  This may bother some users however is there really an advantage today of using SHA512 vs SHA256?  Not in my opinion as it stands today.

The only negative facts by using SHA512 is that it takes longer to create the hashes (more than twice as long), and with DSA2 3092 bit keys (the longest keys you can make currently) - the 256 leftmost bits of the 512 bit hash product are taken to end up with a resultant 256 bit hash.  So hence you wasted processing time to end up with a 256 bit hash when simply computing a 256 bit hash would have been faster and ended up with a resultant that would be just as "secure" to collision. 

Again if using RSA signing, you can use SHA512 as well as SHA256 and respectively get 512 and 256 bit hashes.

A little off topic, but when SHA3 is named in 2010 or 2011, this entire topic will be a mute point, since the algorithm will be completely different than the classic SHA "family".

I have tried this solution but it does run at the command prompt in XP

%0\..

This evals to the current directory.

So say you had a subdirectory in the current directory:

cd %0\..\<subdirectory>

Another way to do it with xp in a bat file would be to do this

set Current_Drive=%~d0
set Current_Path=%~dp0

echo Current Drive=%Current_Drive%
echo Current Path=%Current_Path%

Not sure if this help you at all?

Good idea -- I didn't think of this option, however at least someone was thinking

I believe the preferred algorithm for gnupg to use is contained in the gpg.conf file.  Usually the preferred cipher and digest (signature) algorithms are chosen via the personal-cipher-preferences and personal-digest-preferences as explained below:

--personal-cipher-preferences string
    Set the list of personal cipher preferences to string. Use gpg2 --version to get a list of available algorithms, and use none to set no preference at all. This allows the user to factor in their own preferred algorithms when algorithms are chosen via recipient key preferences. The most highly ranked cipher in this list is also used for the --symmetric encryption command.
--personal-digest-preferences string
    Set the list of personal digest preferences to string. Use gpg2 --version to get a list of available algorithms, and use none to set no preference at all. This allows the user to factor in their own preferred algorithms when algorithms are chosen via recipient key preferences. The most highly ranked digest algorithm in this list is algo used when signing without encryption (e.g. --clearsign or --sign). The default value is SHA-1.

With each of these choices the string is a comma separated list using either the Sx or Hx notation as specified below (note you can generate this list with your own gpg version by typing at the command line gpg -v --version:

Cipher: IDEA (S1), 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8),
        AES256 (S9), TWOFISH (S10), CAMELLIA128 (S11), CAMELLIA192 (S12),
        CAMELLIA256 (S13)
Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9),
      SHA512 (H10), SHA224 (H11)

So for example to set the cipher preferences I would add the following within the gpg.conf file:
--personal-cipher-preferences S9,S8,S7,S10,S4,S1,S2

Always include 3DES -> This is considered the default cipher

SHA1 is considered the default hash

Please note the Camellia ciphers are considered experimental, and unless you have compiled your gpg version from source, neither the IDEA or Camellia ciphers will be available in the "stock" installation.  Camellia ciphers are likely to be added to the "stock" installation, once Camellia is officially recognized by the OpenGPG committee (unsure on the time-table of this decision).