security-and-privacy/gnupg
security-and-privacy/gnupg
1
0
Fork 0
mirror of git://git.gnupg.org/gnupg.git synced 2025-01-03 12:11:33 +01:00
Code Activity

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

Browse Source
This commit is contained in:
Werner Koch 1999-04-06 18:04:55 +00:00
parent 88d44edc56
commit 1b9a820c19
12 changed files with 145 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
BUGS
View File

@ -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

7
cipher/ChangeLog
View File

@ -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.

3
cipher/cipher.c
View File

@ -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;

9
cipher/random.c
View File

@ -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
View File

@ -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
View File

@ -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
View File

@ -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.

9
g10/ChangeLog
View File

@ -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

34
g10/build-packet.c
View File

@ -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 );

7
g10/import.c
View File

@ -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],

5
include/ChangeLog
View File

@ -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.

2
include/cipher.h
View File

@ -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;