See ChangeLog: Tue Apr 6 19:58:12 CEST 1999 Werner Koch

12 files changed, 145 insertions, 53 deletions

diff --git a/BUGS b/BUGS
index 785a1d656..ab9c95f25 100644
--- a/BUGS
+++ b/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
diff --git a/cipher/ChangeLog b/cipher/ChangeLog
index bfb5860f3..b1000c8f7 100644
--- a/cipher/ChangeLog
+++ b/cipher/ChangeLog
@@ -1,3 +1,10 @@
+Tue Apr  6 19:58:12 CEST 1999  Werner Koch  <[email protected]>
+
+	* 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  <[email protected]>
 
 	* rndlinux.c (tty_printf) [IS_MODULE]: Removed.
diff --git a/cipher/cipher.c b/cipher/cipher.c
index ca79fa9b7..338b2b9d2 100644
--- a/cipher/cipher.c
+++ b/cipher/cipher.c
@@ -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;
diff --git a/cipher/random.c b/cipher/random.c
index eedfcfa65..a201c1dbb 100644
--- a/cipher/random.c
+++ b/cipher/random.c
@@ -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;
 }
 
diff --git a/doc/FAQ b/doc/FAQ
index 751d99c20..97bf94a05 100644
--- a/doc/FAQ
+++ b/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.
 
diff --git a/doc/HACKING b/doc/HACKING
index 17ac7426f..24119a827 100644
--- a/doc/HACKING
+++ b/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]
 
 
diff --git a/doc/OpenPGP b/doc/OpenPGP
index e461df78d..a32da4723 100644
--- a/doc/OpenPGP
+++ b/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.
diff --git a/g10/ChangeLog b/g10/ChangeLog
index 274637a4b..91a45a931 100644
--- a/g10/ChangeLog
+++ b/g10/ChangeLog
@@ -1,3 +1,12 @@
+Tue Apr  6 19:58:12 CEST 1999  Werner Koch  <[email protected]>
+
+	* 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  <[email protected]>
 
 	* armor.c (fake_packet): Fix for not not-dash-escaped
diff --git a/g10/build-packet.c b/g10/build-packet.c
index 810bd0dc2..ca0837f6b 100644
--- a/g10/build-packet.c
+++ b/g10/build-packet.c
@@ -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 );
diff --git a/g10/import.c b/g10/import.c
index 920aafbea..deab7f4bd 100644
--- a/g10/import.c
+++ b/g10/import.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],
diff --git a/include/ChangeLog b/include/ChangeLog
index bbb1bc1c9..0fa6e9916 100644
--- a/include/ChangeLog
+++ b/include/ChangeLog
@@ -1,3 +1,8 @@
+Tue Apr  6 19:58:12 CEST 1999  Werner Koch  <[email protected]>
+
+	* cipher.h (DEK): increased max. key length to 32 bytes
+
+
 Sat Feb 20 21:40:49 CET 1999  Werner Koch  <[email protected]>
 
 	* g10lib.h: Removed file and changed all files that includes this.
diff --git a/include/cipher.h b/include/cipher.h
index 3c4edc7ce..75a7b7175 100644
--- a/include/cipher.h
+++ b/include/cipher.h
@@ -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;