security-and-privacy/gnupg
security-and-privacy/gnupg
1
0
Fork 0
mirror of git://git.gnupg.org/gnupg.git synced 2025-07-03 22:56:33 +02:00
Code Activity

* pkclist.c (algo_available): PGP 8 can use the SHA-256 hash.

Browse source 
* sign.c (sign_file, clearsign_file, sign_symencrypt_file): Remove unused
code.
This commit is contained in:
David Shaw 2003-04-04 22:45:22 +00:00
parent 30a3c7b2b6
commit f4a70a3dd4
3 changed files with 29 additions and 21 deletions
Download patch file Download diff file Expand all files Collapse all files

30
g10/pkclist.c
View file

@ -1063,18 +1063,18 @@ build_pk_list( STRLIST rcpts, PK_LIST *ret_pk_list, unsigned use )
CAST5 (3), all hashes except MD5 (1), SHA1 (2), and RIPEMD160 (3),
and all compressions except none (0) and ZIP (1). pgp7 and pgp8
mode expands the cipher list to include AES128 (7), AES192 (8),
AES256 (9), and TWOFISH (10). For a true PGP key all of this is
unneeded as they are the only items present in the preferences
subpacket, but checking here covers the weird case of encrypting to
a key that had preferences from a different implementation which
was then used with PGP. I am not completely comfortable with this
as the right thing to do, as it slightly alters the list of what
the user is supposedly requesting. It is not against the RFC
however, as the preference chosen will never be one that the user
didn't specify somewhere ("The implementation may use any mechanism
to pick an algorithm in the intersection"), and PGP has no
mechanism to fix such a broken preference list, so I'm including
it. -dms */
AES256 (9), and TWOFISH (10). pgp8 adds the SHA-256 hash (8). For
a true PGP key all of this is unneeded as they are the only items
present in the preferences subpacket, but checking here covers the
weird case of encrypting to a key that had preferences from a
different implementation which was then used with PGP. I am not
completely comfortable with this as the right thing to do, as it
slightly alters the list of what the user is supposedly requesting.
It is not against the RFC however, as the preference chosen will
never be one that the user didn't specify somewhere ("The
implementation may use any mechanism to pick an algorithm in the
intersection"), and PGP has no mechanism to fix such a broken
preference list, so I'm including it. -dms */
static int
algo_available( int preftype, int algo, void *hint )
@ -1099,8 +1099,10 @@ algo_available( int preftype, int algo, void *hint )
if(bits && (bits != md_digest_length(algo)))
return 0;
if( (opt.pgp6 || opt.pgp7 || opt.pgp8 )
&& ( algo != 1 && algo != 2 && algo != 3) )
if( (opt.pgp6 || opt.pgp7) && (algo != 1 && algo != 2 && algo != 3) )
return 0;
if( opt.pgp8 && (algo != 1 && algo != 2 && algo != 3 && algo != 8))
return 0;
return algo && !check_digest_algo( algo );