mirror of git://git.gnupg.org/gnupg.git
See ChangeLog: Tue Apr 6 19:58:12 CEST 1999 Werner Koch
This commit is contained in:
Werner Koch
parent
88d44edc56
commit
1b9a820c19
14
BUGS
14
BUGS
|
|
@ -50,21 +50,19 @@ and after about half a day in the rsync snapshots.
|
|||
|
||||
[ *] #13 1999-04-05
|
||||
Trying to generate very large keys fails with a BUG in read_pool()
|
||||
FIX: 1999-04-06
|
||||
|
||||
|
||||
[ *] #14 1999-04-05 <anonymous>
|
||||
If you have the following lines in your "options" file:
|
||||
load-extension twofish
|
||||
cipher-algo twofish
|
||||
s2k-cipher-algo twofish
|
||||
and then try to "gpg --gen-key", everything goes along fine until you
|
||||
verify your password. Then the program crashes with a BUG at line 226
|
||||
of passphrase.c.
|
||||
If you use --s2k-cipher-algo twofish, the the program crashes with
|
||||
a BUG at line 226 of passphrase.c.
|
||||
FIX: 1999-04-06
|
||||
|
||||
|
||||
[ **] #15 199-04-05
|
||||
[ **] #15 1999-04-05
|
||||
Hash calculation for subkey bindings is not according to rfc2440 if
|
||||
a 4 byte length header is used for the subkey.
|
||||
FIX: 1999-04-06
|
||||
|
||||
|
||||
Next #16
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
Tue Apr 6 19:58:12 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
|
||||
|
||||
* random.c (get_random_bits): Can now handle requests > POOLSIZE
|
||||
|
||||
* cipher.c (cipher_open): Now uses standard CFB for automode if
|
||||
the blocksize is gt 8 (according to rfc2440).
|
||||
|
||||
Sat Mar 20 11:44:21 CET 1999 Werner Koch <wk@isil.d.shuttle.de>
|
||||
|
||||
* rndlinux.c (tty_printf) [IS_MODULE]: Removed.
|
||||
|
|
|
|||
|
|
@ -340,7 +340,8 @@ cipher_open( int algo, int mode, int secure )
|
|||
if( algo == CIPHER_ALGO_DUMMY )
|
||||
hd->mode = CIPHER_MODE_DUMMY;
|
||||
else if( mode == CIPHER_MODE_AUTO_CFB ) {
|
||||
if( algo == CIPHER_ALGO_BLOWFISH160 || algo >= 100 )
|
||||
if( hd->blocksize > 8
|
||||
|| algo == CIPHER_ALGO_BLOWFISH160 || algo >= 100 )
|
||||
hd->mode = CIPHER_MODE_CFB;
|
||||
else
|
||||
hd->mode = CIPHER_MODE_PHILS_CFB;
|
||||
|
|
|
|||
|
|
@ -169,14 +169,19 @@ random_is_faked()
|
|||
byte *
|
||||
get_random_bits( size_t nbits, int level, int secure )
|
||||
{
|
||||
byte *buf;
|
||||
byte *buf, *p;
|
||||
size_t nbytes = (nbits+7)/8;
|
||||
|
||||
if( quick_test && level > 1 )
|
||||
level = 1;
|
||||
MASK_LEVEL(level);
|
||||
buf = secure && secure_alloc ? m_alloc_secure( nbytes ) : m_alloc( nbytes );
|
||||
read_pool( buf, nbytes, level );
|
||||
for( p = buf; nbytes > 0; ) {
|
||||
size_t n = nbytes > POOLSIZE? POOLSIZE : nbytes;
|
||||
read_pool( p, n, level );
|
||||
nbytes -= n;
|
||||
p += n;
|
||||
}
|
||||
return buf;
|
||||
}
|
||||
|
||||
|
|
|
|||
30
doc/FAQ
30
doc/FAQ
|
|
@ -93,10 +93,10 @@
|
|||
a v3 packet. GNUPG is the only program which had used
|
||||
these v3 ElGamal keys - so this assumption is quite safe.
|
||||
|
||||
Q: Why is PGP 5.x not able to encrypt messages with my public key?
|
||||
Q: Why is PGP 5.x not able to encrypt messages with some keys?
|
||||
A: PGP Inc refuses to accept ElGamal keys of type 20 even for
|
||||
encryption. They only supports type 16 (which are identical
|
||||
at least for decryption). To be more inter-operable, GNUPG
|
||||
encryption. They only support type 16 (which is identical
|
||||
at least for decryption). To be more inter-operable, GnuPG
|
||||
(starting with version 0.3.3) now also uses type 16 for the
|
||||
ElGamal subkey which is created if the default key algorithm
|
||||
is chosen. You may add an type 16 ElGamal key to your public
|
||||
|
|
@ -104,7 +104,7 @@
|
|||
|
||||
Q: Why is PGP 5.x not able to verify my messages?
|
||||
A: PGP 5.x does not accept V4 signatures for data material but
|
||||
OpenPGP requires generation of V3 signatures for all kind of
|
||||
OpenPGP requires generation of V4 signatures for all kind of
|
||||
data. Use the option "--force-v3-sigs" to generate V3 signatures
|
||||
for data.
|
||||
|
||||
|
|
@ -127,11 +127,10 @@
|
|||
Q: How can I conventional encrypt a message, so that PGP can decrypt it?
|
||||
A: You can't do this for PGP 2. For PGP 5 you should use this:
|
||||
|
||||
gpg -c --cipher-algo 3des --compress-algo 1 --no-comment myfile
|
||||
gpg -c --cipher-algo 3des --compress-algo 1 myfile
|
||||
|
||||
You may replace "3des" by "cast5". "blowfish" does not work with
|
||||
all versions of pgp5. You may also want to put
|
||||
no-comment
|
||||
compress-algo 1
|
||||
into your ~/.gnupg/options file - this does not affect normal
|
||||
gnupg operation.
|
||||
|
|
@ -151,7 +150,7 @@
|
|||
(a program (look at your daemons) that reads from /dev/[u]random).
|
||||
|
||||
Q: And it really takes long when I work on a remote system. Why?
|
||||
A: Don't do this at all! You should never create keys or even use gnupg
|
||||
A: Don't do this at all! You should never create keys or even use GnuPG
|
||||
on a remote system because you normally have no physical control over
|
||||
your secret keyring (which is in most cases vulnerable to advanced
|
||||
dictionary attacks) - I strongly encourage everyone to only create keys
|
||||
|
|
@ -160,7 +159,7 @@
|
|||
sure to have a strong password for your account and for your secret key
|
||||
and trust your Root.
|
||||
|
||||
When I check gnupg on a remote system via ssh (I have no Alpha here ;-)
|
||||
When I check GnuPG on a remote system via ssh (I have no Alpha here ;-)
|
||||
I have the same problem. It takes a *very* long time to create the
|
||||
keys, so I use a special option, --quick-random, to generate insecure
|
||||
keys which are only good for some tests.
|
||||
|
|
@ -171,14 +170,13 @@
|
|||
computed at the time it is needed. This is one of the reasons for the
|
||||
trustdb which holds a list of valid key signatures. If you are not
|
||||
running in batch mode you will be asked to assign a trust parameter
|
||||
(ownertrust) to a key. I have plans to use a cache for calculated
|
||||
trust values to speed up calculation.
|
||||
(ownertrust) to a key.
|
||||
|
||||
You can see the validity (calculated trust value) using this command.
|
||||
|
||||
gpgm --list-keys --with-colons
|
||||
|
||||
If the first field is "pub", the second field shows you the trust:
|
||||
If the first field is "pub" or "uid", the second field shows you the trust:
|
||||
|
||||
o = Unknown (this key is new to the system)
|
||||
e = The key has expired
|
||||
|
|
@ -190,6 +188,8 @@
|
|||
is only used for keys for which
|
||||
the secret key is also available.
|
||||
|
||||
The value in the "pub" record is the best one of all "uid" records.
|
||||
|
||||
You can get a list of the assigned trust values (how much you trust
|
||||
the owner to correctly sign another person's key)
|
||||
|
||||
|
|
@ -271,15 +271,15 @@
|
|||
|
||||
Q: What is trust, validity and ownertrust?
|
||||
A: "ownertrust" is used instead of "trust" to make clear that
|
||||
this is the value you have assigned to key to express how much you
|
||||
this is the value you have assigned to a key to express how much you
|
||||
trust the owner of this key to correctly sign (and so introduce)
|
||||
other keys. "validity", or calculated trust, is a value which
|
||||
says how much the gnupg thinks a key is valid (that it really belongs
|
||||
says how much GnuPG thinks a key is valid (that it really belongs
|
||||
to the one who claims to be the owner of the key).
|
||||
For more see the chapter "The Web of Trust" in the
|
||||
Manual [gpg: Oops: Internal error: manual not found - sorry]
|
||||
|
||||
Q: How do interpret some of the informational outputs?
|
||||
Q: How do I interpret some of the informational outputs?
|
||||
A: While checking the validity of a key, GnuPG sometimes prints
|
||||
some information which is prefixed with information about
|
||||
the checked item.
|
||||
|
|
@ -327,6 +327,6 @@
|
|||
the displayed charset is the one you have activated on your system
|
||||
"iso-8859-1" is the most used one, so this is the default. You can
|
||||
change the charset with the option "--charset". It is important that
|
||||
you active characterset matches the one displayed - if not restrict
|
||||
you active characterset matches the one displayed - if not, restrict
|
||||
yourself to plain 7 bit ASCII and no mapping has to be done.
|
||||
|
||||
|
|
|
|||
51
doc/HACKING
51
doc/HACKING
|
|
@ -33,6 +33,14 @@ by sending a mail with "subscribe" in the body to
|
|||
Please run scripts/autogen.sh to create some required files.
|
||||
|
||||
|
||||
RSYNC access
|
||||
============
|
||||
The FTP archive is also available by anonymous rsync. A daily snapshot
|
||||
of the CVS head revision is also available. See rsync(1) and try
|
||||
"rsync ftp.gnupg.org::" to see available resources.
|
||||
|
||||
|
||||
|
||||
RFCs
|
||||
====
|
||||
|
||||
|
|
@ -86,8 +94,8 @@ Directory Layout
|
|||
./cipher Cryptographic functions
|
||||
./g10 GnuPG application
|
||||
./tools Some helper and demo programs
|
||||
./keybox The keybox library
|
||||
./gcrypt Stuff needed to build libgcrypt
|
||||
./keybox The keybox library (under construction)
|
||||
./gcrypt Stuff needed to build libgcrypt (under construction)
|
||||
|
||||
|
||||
|
||||
|
|
@ -127,13 +135,20 @@ The same option table is also used to parse resource files.
|
|||
|
||||
|
||||
|
||||
What is an iobuf
|
||||
What is an IOBUF
|
||||
----------------
|
||||
This is the data structure used for most I/O of gnupg. It is similar
|
||||
to System V Streams but much simpler. It should be replaced by a cleaner
|
||||
and faster implementation. We are doing to much copying and the semantics
|
||||
of "filter" removing are not very clean. EOF handling is also a problem.
|
||||
|
||||
to System V Streams but much simpler. Because OpenPGP messages are nested
|
||||
in different ways; the use of such a system has big advantages. Here is
|
||||
an example, how it works: If the parser sees a packet header with a partial
|
||||
length, it pushes the block_filter onto the IOBUF to handle these partial
|
||||
length packets: from now on you don't have to worry about this. When it sees
|
||||
a compressed packet it pushes the uncompress filter and the next read byte
|
||||
is one which has already been uncompressed by this filter. Same goes for
|
||||
enciphered packet, plaintext packets and so on. The file g10/encode.c
|
||||
might be a good staring point to see how it is used - actually this is
|
||||
the other way: constructing messages using pushed filters but it may be
|
||||
easier to understand.
|
||||
|
||||
|
||||
How to use the message digest functions
|
||||
|
|
@ -171,11 +186,33 @@ Both methods may be combined. [Please see the source for the real syntax]
|
|||
|
||||
How to use the cipher functions
|
||||
-------------------------------
|
||||
cipher/cipher.c implements the interface to symmetric encryption functions.
|
||||
As usual you have a function to open a cipher (which returns a handle to be used
|
||||
with all other functions), some functions to set the key and other stuff and
|
||||
a encrypt and decrypt function which does the real work. YOu probably know
|
||||
how to work with files - so it should really be easy to work with these
|
||||
functions. Here is an example:
|
||||
|
||||
CIPHER_HANDLE hd;
|
||||
|
||||
hd = cipher_open( CIPHER_ALGO_TWOFISH, CIPHER_MODE_CFB, 0 );
|
||||
if( !hd )
|
||||
oops( use other funtion to check for the real error );
|
||||
rc = cipher_setkey( hd, key256bit, 32 ) )
|
||||
if( rc )
|
||||
oops( weak key or something like this );
|
||||
cipher_setiv( hd, some_IV_or_NULL_for_all_zeroes );
|
||||
cipher_encrypt( hd, plain, cipher, size );
|
||||
cipher_close( hd );
|
||||
|
||||
|
||||
|
||||
How to use the public key functions
|
||||
-----------------------------------
|
||||
cipher/pubkey.c implements the interface to asymmetric encryption and
|
||||
signature functions. This is basically the same as with the symmetric
|
||||
counterparts, but due to their nature it is a little bit more complicated.
|
||||
|
||||
[Give an example]
|
||||
|
||||
|
||||
|
|
|
|||
27
doc/OpenPGP
27
doc/OpenPGP
|
|
@ -2,7 +2,7 @@
|
|||
=================
|
||||
|
||||
See RFC2440 for a description of OpenPGP. I have an annotated version
|
||||
of this RFC online: http://www.d.shuttle.de/isil/gnupg/rfc2440.html
|
||||
of this RFC online: http://www.gnupg.org/rfc2440.html
|
||||
|
||||
|
||||
|
||||
|
|
@ -10,15 +10,6 @@
|
|||
===================
|
||||
GnuPG (>0.4.5) is in compliance with RFC2440 despite these exceptions:
|
||||
|
||||
===> Please can someone check this <=========
|
||||
|
||||
* (5.2) GnuPG generates V4 signatures for all V4 keys. The option
|
||||
--force-v3-sigs allows to override.
|
||||
|
||||
* (5.3) GnuPG has an option to use simple S2K for "Symmetric-Key
|
||||
Encrypted Session-Key Packets"; however a warning message is
|
||||
issued if this option is active.
|
||||
|
||||
* (9.1) states that RSA SHOULD be implemented. This is not done
|
||||
(except with an extension, usable outside the U.S.) due to
|
||||
patent problems.
|
||||
|
|
@ -26,13 +17,6 @@
|
|||
* (9.2) states that IDEA SHOULD be implemented. This is not done
|
||||
due to patent problems.
|
||||
|
||||
* (12.1) states that an implementation MUST NOT use a symmetric
|
||||
algorithm which is not in the preference list. GnuPG has an
|
||||
option to override this.
|
||||
|
||||
* A special format of partial packet length exists for v3 packets
|
||||
which can be considered to be in compliance with RFC1991; this
|
||||
format is only created if a special option is active.
|
||||
|
||||
All MAY features are implemented with this exception:
|
||||
|
||||
|
|
@ -41,14 +25,21 @@
|
|||
|
||||
Most of the OPTIONAL stuff is implemented.
|
||||
|
||||
There are a couple of options which can be used to override some
|
||||
RFC requirements. This is always mentioned with the description
|
||||
of that options.
|
||||
|
||||
A special format of partial packet length exists for v3 packets
|
||||
which can be considered to be in compliance with RFC1991; this
|
||||
format is only created if a special option is active.
|
||||
|
||||
|
||||
Some Notes on OpenPGP / PGP Compatibility:
|
||||
==========================================
|
||||
|
||||
* PGP 5.x does not accept V4 signatures for anything other than
|
||||
key material.
|
||||
key material. The GnuPG option --force-v3-sigs mimics this
|
||||
behaviour.
|
||||
|
||||
* PGP 5.x does not recognize the "five-octet" lengths in
|
||||
new-format headers or in signature subpacket lengths.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,12 @@
|
|||
Tue Apr 6 19:58:12 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
|
||||
|
||||
* armor.c: Removed duped include (John Bley)
|
||||
* mainproc.c: Ditto.
|
||||
|
||||
* build-packet.c (hash_public_key): Fixed hashing of the header.
|
||||
|
||||
* import.c (delete_inv_parts): Allow import of own non-exportable sigs.
|
||||
|
||||
Sat Mar 20 13:59:47 CET 1999 Werner Koch <wk@isil.d.shuttle.de>
|
||||
|
||||
* armor.c (fake_packet): Fix for not not-dash-escaped
|
||||
|
|
|
|||
|
|
@ -241,6 +241,8 @@ hash_public_key( MD_HANDLE md, PKT_public_key *pk )
|
|||
{
|
||||
PACKET pkt;
|
||||
int rc = 0;
|
||||
int ctb;
|
||||
ulong pktlen;
|
||||
int c;
|
||||
IOBUF a = iobuf_temp();
|
||||
#if 0
|
||||
|
|
@ -256,6 +258,38 @@ hash_public_key( MD_HANDLE md, PKT_public_key *pk )
|
|||
pkt.pkt.public_key = pk;
|
||||
if( (rc = build_packet( a, &pkt )) )
|
||||
log_fatal("build public_key for hashing failed: %s\n", g10_errstr(rc));
|
||||
/* skip the constructed header */
|
||||
ctb = iobuf_get_noeof(a);
|
||||
pktlen = 0;
|
||||
if( (ctb & 0x40) ) {
|
||||
c = iobuf_get_noeof(a);
|
||||
if( c < 192 )
|
||||
pktlen = c;
|
||||
else if( c < 224 ) {
|
||||
pktlen = (c - 192) * 256;
|
||||
c = iobuf_get_noeof(a);
|
||||
pktlen += c + 192;
|
||||
}
|
||||
else if( c == 255 ) {
|
||||
pktlen = iobuf_get_noeof(a) << 24;
|
||||
pktlen |= iobuf_get_noeof(a) << 16;
|
||||
pktlen |= iobuf_get_noeof(a) << 8;
|
||||
pktlen |= iobuf_get_noeof(a);
|
||||
}
|
||||
}
|
||||
else {
|
||||
int lenbytes = ((ctb&3)==3)? 0 : (1<<(ctb & 3));
|
||||
for( ; lenbytes; lenbytes-- ) {
|
||||
pktlen <<= 8;
|
||||
pktlen |= iobuf_get_noeof(a);
|
||||
}
|
||||
}
|
||||
/* hash a header */
|
||||
md_putc( md, 0x99 );
|
||||
pktlen &= 0xffff; /* can't handle longer packets */
|
||||
md_putc( md, pktlen >> 8 );
|
||||
md_putc( md, pktlen & 0xff );
|
||||
/* hash the packet body (don't use pktlen here!) */
|
||||
while( (c=iobuf_get(a)) != -1 ) {
|
||||
#if 0
|
||||
fprintf( fp," %02x", c );
|
||||
|
|
|
|||
|
|
@ -796,7 +796,12 @@ delete_inv_parts( const char *fname, KBNODE keyblock, u32 *keyid )
|
|||
else if( node->pkt->pkttype == PKT_SIGNATURE
|
||||
&& (p = parse_sig_subpkt2( node->pkt->pkt.signature,
|
||||
SIGSUBPKT_EXPORTABLE, NULL ))
|
||||
&& !*p ) {
|
||||
&& !*p
|
||||
&& seckey_available( node->pkt->pkt.signature->keyid ) ) {
|
||||
/* here we violate the rfc a bit by still allowing
|
||||
* to import non-exportable signature when we have the
|
||||
* the secret key used to create this signature - it
|
||||
* seems that this makes sense */
|
||||
log_info_f(fname, _("key %08lX: non exportable signature "
|
||||
"(class %02x) - skipped\n"),
|
||||
(ulong)keyid[1],
|
||||
|
|
|
|||
|
|
@ -1,3 +1,8 @@
|
|||
Tue Apr 6 19:58:12 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
|
||||
|
||||
* cipher.h (DEK): increased max. key length to 32 bytes
|
||||
|
||||
|
||||
Sat Feb 20 21:40:49 CET 1999 Werner Koch <wk@isil.d.shuttle.de>
|
||||
|
||||
* g10lib.h: Removed file and changed all files that includes this.
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@
|
|||
typedef struct {
|
||||
int algo;
|
||||
int keylen;
|
||||
byte key[24]; /* this is the largest used keylen (3des) */
|
||||
byte key[32]; /* this is the largest used keylen (256 bit) */
|
||||
} DEK;
|
||||
|
||||
struct cipher_handle_s;
|
||||
|
|
|
|||
Loading…
Reference in New Issue