mirror of
git://git.gnupg.org/gnupg.git
synced 2024-12-22 10:19:57 +01:00
See ChangeLog: Mon Sep 13 10:55:14 CEST 1999 Werner Koch
This commit is contained in:
parent
d92e4db7fd
commit
52139a60cf
1
BUGS
1
BUGS
@ -47,6 +47,7 @@ and after about half a day in the rsync snapshots.
|
||||
[ *] #23 1999-09-03 <todd.brooks@yale.edu> 0.9.11
|
||||
Only the first signature of a cleartext sig seems to be verified.
|
||||
Can't fix it in 1.0 because the code is semi-frozen.
|
||||
HMMM: Can't reprodude the bug here - it just works. Check wehther
|
||||
|
||||
[ *] #24 1999-09-05 <marcus@yoyo.cc.monash.edu.au> 0.9.11
|
||||
Does not link libc and libz expect when removing all "-lc -lz" except
|
||||
|
31
THOUGHTS
31
THOUGHTS
@ -1,5 +1,12 @@
|
||||
How often have we to do a key lookup by mailaddress?.
|
||||
can this be accomplished by an external program?
|
||||
|
||||
|
||||
|
||||
What about using S-Exp to describe the interface to the ciphers instead
|
||||
of simply iterating over them. This way we can easy register a name which
|
||||
can be used as the "hintstr" for --load-extension.
|
||||
|
||||
EGD
|
||||
====
|
||||
Oh, and on embedding egd into the gpg package: I think if you just unpack it
|
||||
@ -48,8 +55,8 @@ From: Matthew Skala <mskala@ansuz.sooke.bc.ca>
|
||||
|
||||
|
||||
|
||||
-----BEGIN PGP SIGNED MESSAGE-----
|
||||
Hash: SHA1
|
||||
==============================
|
||||
[ "-->" indicates a comment by me (wk) ]
|
||||
|
||||
Hi Werner..
|
||||
|
||||
@ -83,11 +90,16 @@ extension mechanisms in GPG should be enough to try various ways later on.
|
||||
|
||||
1) pass an argument string to loadable extension modules (maybe
|
||||
gpg --load-extension foofish=arg1,arg2,arg3 ?)
|
||||
--> could also be achived by S-Exps
|
||||
|
||||
2) allow multiple instances of the same extension module (presumably with
|
||||
different arguments)
|
||||
--> set an alias name when loading them
|
||||
3) allow extension modules to use stdin/stdout/stderr as normal (probably
|
||||
already in there), for giving feedback to the user, or possibly asking them
|
||||
for a password of some sort
|
||||
--> there should really be some kind of callback mechanism.
|
||||
|
||||
4) have an extension to provide secret keys:
|
||||
|
||||
It looks like most of the hooks for this are already in place, it just
|
||||
@ -97,6 +109,9 @@ extension mechanisms in GPG should be enough to try various ways later on.
|
||||
an argument. When the keyblock resource is asked to enumerate its keys, it
|
||||
runs the external program (first with a "0" argument, then a "1", and so on
|
||||
until the program reports that no more keys are available). The external
|
||||
--> better use a cookie: This way we are also stateless but have a more
|
||||
general interface.
|
||||
|
||||
program returns one (possibly armored) secret key block each time. The
|
||||
program might have some kind of special protocol to talk to the storage
|
||||
device. One thing that comes to mind is to simply include a random number
|
||||
@ -108,6 +123,8 @@ extension mechanisms in GPG should be enough to try various ways later on.
|
||||
much processing power and IO is available on the device. But the same
|
||||
extension module should be able to handle as complex a scheme as one could
|
||||
wish.
|
||||
--> authenticate the session on startup, using DH and the mentioned
|
||||
cookie/screen/keyboard authentication.
|
||||
|
||||
The current keyblock-resource interface would work fine, although it
|
||||
might be more convenient if a resource could be asked for a key by id
|
||||
@ -118,10 +135,13 @@ extension mechanisms in GPG should be enough to try various ways later on.
|
||||
to fetch by id (which would require it to fall back to the other keyblock
|
||||
resources if it failed), the user's device might be asked to release the
|
||||
key even though some other secret key was the one needed.
|
||||
--> Right.
|
||||
|
||||
|
||||
5) have an extension to perform a secret-key operation without the actual
|
||||
secret key material
|
||||
--> Define a clear interface to do this and in the first step write
|
||||
a daemon which does exactly this.
|
||||
|
||||
basically something to indicate that any decrypt or sign operations that
|
||||
occur for a specific keyid should call the extension module instead. The
|
||||
@ -221,12 +241,17 @@ DJGPP
|
||||
Don't use symlinks but try to do the preprocessing in the config-links script.
|
||||
DJPGG has problems to distinguish betwen .s and .S becaus the FAT filesystem
|
||||
is not case sensitive (Mark Elbrecht).
|
||||
|
||||
Well, it runs only on one architecture and therefor it might be possible
|
||||
to add a special case for it, completely bypassing the symlink autselection
|
||||
trick.
|
||||
|
||||
Special procmail addresses
|
||||
==========================
|
||||
* foo+bar@example.net: Try to match the address without the "+bar".
|
||||
Should be done by the MUA, but maybe we can do this.
|
||||
--> Yep. Another reason to utilize a directory service or something
|
||||
else for keylookup.
|
||||
|
||||
|
||||
|
||||
Suggested things which I will not do:
|
||||
|
@ -1,3 +1,9 @@
|
||||
Mon Sep 13 10:51:29 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
|
||||
|
||||
|
||||
* bithelp.h: New.
|
||||
* rmd160.h, sha1.h, md5.h: Use the rol macro from bithelp.h
|
||||
|
||||
Tue Sep 7 16:23:36 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
|
||||
|
||||
|
||||
|
@ -39,6 +39,7 @@ libcipher_la_SOURCES = cipher.c \
|
||||
md.c \
|
||||
dynload.c \
|
||||
dynload.h \
|
||||
bithelp.h \
|
||||
des.c \
|
||||
des.h \
|
||||
twofish.c \
|
||||
|
41
cipher/bithelp.h
Normal file
41
cipher/bithelp.h
Normal file
@ -0,0 +1,41 @@
|
||||
/* bithelp.h - Some bit manipulation helpers
|
||||
* Copyright (C) 1999 Free Software Foundation, Inc.
|
||||
*
|
||||
* This file is part of GnuPG.
|
||||
*
|
||||
* GnuPG is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License as published by
|
||||
* the Free Software Foundation; either version 2 of the License, or
|
||||
* (at your option) any later version.
|
||||
*
|
||||
* GnuPG is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
|
||||
*/
|
||||
#ifndef G10_BITHELP_H
|
||||
#define G10_BITHELP_H
|
||||
|
||||
|
||||
/****************
|
||||
* Rotate a 32 bit integer by n bytes
|
||||
*/
|
||||
#if defined(__GNUC__) && defined(__i386__)
|
||||
static inline u32
|
||||
rol( u32 x, int n)
|
||||
{
|
||||
__asm__("roll %%cl,%0"
|
||||
:"=r" (x)
|
||||
:"0" (x),"c" (n));
|
||||
return x;
|
||||
}
|
||||
#else
|
||||
#define rol(x,n) ( ((x) << (n)) | ((x) >> (32-(n))) )
|
||||
#endif
|
||||
|
||||
|
||||
#endif /*G10_BITHELP_H*/
|
10
cipher/md5.c
10
cipher/md5.c
@ -37,6 +37,8 @@
|
||||
#include "memory.h"
|
||||
#include "dynload.h"
|
||||
|
||||
#include "bithelp.h"
|
||||
|
||||
|
||||
typedef struct {
|
||||
u32 A,B,C,D; /* chaining variables */
|
||||
@ -104,15 +106,11 @@ transform( MD5_CONTEXT *ctx, byte *data )
|
||||
do \
|
||||
{ \
|
||||
a += FF (b, c, d) + (*cwp++) + T; \
|
||||
CYCLIC (a, s); \
|
||||
a = rol(a, s); \
|
||||
a += b; \
|
||||
} \
|
||||
while (0)
|
||||
|
||||
/* It is unfortunate that C does not provide an operator for
|
||||
cyclic rotation. Hope the C compiler is smart enough. */
|
||||
#define CYCLIC(w, s) (w = (w << s) | (w >> (32 - s)))
|
||||
|
||||
/* Before we start, one word about the strange constants.
|
||||
They are defined in RFC 1321 as
|
||||
|
||||
@ -142,7 +140,7 @@ transform( MD5_CONTEXT *ctx, byte *data )
|
||||
do \
|
||||
{ \
|
||||
a += f (b, c, d) + correct_words[k] + T; \
|
||||
CYCLIC (a, s); \
|
||||
a = rol(a, s); \
|
||||
a += b; \
|
||||
} \
|
||||
while (0)
|
||||
|
@ -29,6 +29,8 @@
|
||||
#include "cipher.h" /* only used for the rmd160_hash_buffer() prototype */
|
||||
#include "dynload.h"
|
||||
|
||||
#include "bithelp.h"
|
||||
|
||||
/*********************************
|
||||
* RIPEMD-160 is not patented, see (as of 25.10.97)
|
||||
* http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html
|
||||
@ -153,19 +155,6 @@ rmd160_init( RMD160_CONTEXT *hd )
|
||||
}
|
||||
|
||||
|
||||
#if defined(__GNUC__) && defined(__i386__)
|
||||
static inline u32
|
||||
rol(int n, u32 x)
|
||||
{
|
||||
__asm__("roll %%cl,%0"
|
||||
:"=r" (x)
|
||||
:"0" (x),"c" (n));
|
||||
return x;
|
||||
}
|
||||
#else
|
||||
#define rol(n,x) ( ((x) << (n)) | ((x) >> (32-(n))) )
|
||||
#endif
|
||||
|
||||
|
||||
/****************
|
||||
* Transform the message X which consists of 16 32-bit-words
|
||||
@ -218,8 +207,8 @@ transform( RMD160_CONTEXT *hd, byte *data )
|
||||
#define F3(x,y,z) ( ((x) & (z)) | ((y) & ~(z)) )
|
||||
#define F4(x,y,z) ( (x) ^ ((y) | ~(z)) )
|
||||
#define R(a,b,c,d,e,f,k,r,s) do { t = a + f(b,c,d) + k + x[r]; \
|
||||
a = rol(s,t) + e; \
|
||||
c = rol(10,c); \
|
||||
a = rol(t,s) + e; \
|
||||
c = rol(c,10); \
|
||||
} while(0)
|
||||
|
||||
/* left lane */
|
||||
|
@ -39,6 +39,7 @@
|
||||
#include "util.h"
|
||||
#include "memory.h"
|
||||
#include "dynload.h"
|
||||
#include "bithelp.h"
|
||||
|
||||
|
||||
typedef struct {
|
||||
@ -49,20 +50,6 @@ typedef struct {
|
||||
} SHA1_CONTEXT;
|
||||
|
||||
|
||||
#if defined(__GNUC__) && defined(__i386__)
|
||||
static inline u32
|
||||
rol(int n, u32 x)
|
||||
{
|
||||
__asm__("roll %%cl,%0"
|
||||
:"=r" (x)
|
||||
:"0" (x),"c" (n));
|
||||
return x;
|
||||
}
|
||||
#else
|
||||
#define rol(n,x) ( ((x) << (n)) | ((x) >> (32-(n))) )
|
||||
#endif
|
||||
|
||||
|
||||
|
||||
|
||||
void
|
||||
@ -123,11 +110,11 @@ transform( SHA1_CONTEXT *hd, byte *data )
|
||||
^ x[(i-8)&0x0f] ^ x[(i-3)&0x0f] \
|
||||
, (x[i&0x0f] = (tm << 1) | (tm >> 31)) )
|
||||
|
||||
#define R(a,b,c,d,e,f,k,m) do { e += rol( 5, a ) \
|
||||
#define R(a,b,c,d,e,f,k,m) do { e += rol( a, 5 ) \
|
||||
+ f( b, c, d ) \
|
||||
+ k \
|
||||
+ m; \
|
||||
b = rol( 30, b ); \
|
||||
b = rol( b, 30 ); \
|
||||
} while(0)
|
||||
R( a, b, c, d, e, F1, K1, x[ 0] );
|
||||
R( e, a, b, c, d, F1, K1, x[ 1] );
|
||||
|
16
doc/FAQ
16
doc/FAQ
@ -232,7 +232,7 @@
|
||||
abbreviated -o) is an option that takes a filename. The option's argument
|
||||
must follow immediately after the option itself, otherwise gpg doesn't know
|
||||
which option the argument is supposed to go with. As an option, --output and
|
||||
its filename must come before the command. The --remote-user (-r) option takes
|
||||
its filename must come before the command. The --recipient (-r) option takes
|
||||
a name or keyid to encrypt the message to, which must come right after the -r
|
||||
argument. The --encrypt (or -e) command comes after all the options followed
|
||||
by the file you wish to encrypt. So use
|
||||
@ -241,22 +241,22 @@
|
||||
|
||||
If you write the options out in full, it is easier to read
|
||||
|
||||
gpg --remote-user alice --output secret.txt --encrypt test.txt
|
||||
gpg --recipient alice --output secret.txt --encrypt test.txt
|
||||
|
||||
If you're saving it in a file called ".txt" then you'd probably expect to see
|
||||
ASCII-armored text in there, so you need to add the --armor (-a) option,
|
||||
which doesn't take any arguments.
|
||||
|
||||
gpg --armor --remote-user alice --output secret.txt --encrypt test.txt
|
||||
gpg --armor --recipient alice --output secret.txt --encrypt test.txt
|
||||
|
||||
If you imagine square brackets around the optional parts, it becomes a bit
|
||||
clearer:
|
||||
|
||||
gpg [--armor] [--remote-user alice] [--output secret.txt] --encrypt test.txt
|
||||
gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt
|
||||
|
||||
The optional parts can be rearranged any way you want.
|
||||
|
||||
gpg --output secret.txt --remote-user alice --armor --encrypt test.txt
|
||||
gpg --output secret.txt --recipient alice --armor --encrypt test.txt
|
||||
|
||||
If your filename begins with a hyphen (e.g. "-a.txt"), gnupg assumes this is
|
||||
an option and may complain. To avoid this you have either to use
|
||||
@ -282,8 +282,7 @@
|
||||
other keys. "validity", or calculated trust, is a value which
|
||||
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]
|
||||
For more see the chapter "The Web of Trust" in the Manual
|
||||
|
||||
Q: How do I interpret some of the informational outputs?
|
||||
A: While checking the validity of a key, GnuPG sometimes prints
|
||||
@ -340,5 +339,6 @@
|
||||
A: There is a script in the tools directory to help you:
|
||||
After you have imported the PGP keyring you can give this command:
|
||||
$ lspgpot pgpkeyring | gpg --import-ownertrust
|
||||
|
||||
where pgpkeyring is the original keyring and not the GnuPG one you
|
||||
might have created in the first step.
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
GnuPG and OpenPGP
|
||||
=================
|
||||
|
||||
See RFC2440 for a description of OpenPGP. I have an annotated version
|
||||
See RFC2440 for a description of OpenPGP. We have an annotated version
|
||||
of this RFC online: http://www.gnupg.org/rfc2440.html
|
||||
|
||||
|
||||
|
@ -1,3 +1,10 @@
|
||||
Mon Sep 13 10:51:29 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
|
||||
|
||||
|
||||
* signal.c (got_fatal_signal): Print message using write(2) and
|
||||
only for development versions.
|
||||
|
||||
|
||||
Mon Sep 6 19:59:08 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
|
||||
|
||||
* tdbio.c (tdbio_set_dbname): Use mkdir macro
|
||||
|
22
g10/signal.c
22
g10/signal.c
@ -1,5 +1,5 @@
|
||||
/* signal.c - signal handling
|
||||
* Copyright (C) 1998 Free Software Foundation, Inc.
|
||||
* Copyright (C) 1998, 1999 Free Software Foundation, Inc.
|
||||
*
|
||||
* This file is part of GnuPG.
|
||||
*
|
||||
@ -39,28 +39,34 @@ static volatile int caught_fatal_sig = 0;
|
||||
static volatile int caught_sigusr1 = 0;
|
||||
|
||||
static const char *
|
||||
signal_name( int signum )
|
||||
get_signal_name( int signum )
|
||||
{
|
||||
#if defined(SYS_SIGLIST_DECLARED) && defined(NSIG)
|
||||
return (signum >= 0 && signum < NSIG) ? sys_siglist[signum] : "?";
|
||||
#else
|
||||
static char buf[20];
|
||||
sprintf(buf, "signal %d", signum );
|
||||
return buf;
|
||||
return "some signal";
|
||||
#endif
|
||||
}
|
||||
|
||||
|
||||
static RETSIGTYPE
|
||||
got_fatal_signal( int sig )
|
||||
{
|
||||
const char *s;
|
||||
|
||||
if( caught_fatal_sig )
|
||||
raise( sig );
|
||||
caught_fatal_sig = 1;
|
||||
|
||||
fprintf( stderr, "\n%s: %s caught ... exiting\n",
|
||||
log_get_name(), signal_name(sig) );
|
||||
secmem_term();
|
||||
exit( 8 );
|
||||
#ifdef IS_DEVELOPMENT_VERSION
|
||||
write(2, "\n", 1 );
|
||||
s = log_get_name(); if( s ) write(2, s, strlen(s) );
|
||||
write(2, ": ", 2 );
|
||||
s = get_signal_name(sig); write(2, s, strlen(s) );
|
||||
write(2, " caught ... exiting\n", 21 );
|
||||
#endif
|
||||
exit(8); /* Hmmm, for some reasons rais2e does not work */
|
||||
}
|
||||
|
||||
|
||||
|
@ -370,6 +370,16 @@ m_is_secure( const void *p )
|
||||
return p >= pool && p < (void*)((char*)pool+poolsize);
|
||||
}
|
||||
|
||||
|
||||
|
||||
/****************
|
||||
* Warning: This code might be called by an interrupt handler
|
||||
* and frankly, thre should really be such a handler,
|
||||
* to make sure that the memory is wiped out.
|
||||
* We hope that the OS wipes out mlocked memory after
|
||||
* receiving a SIGKILL - it really should do so, otherwise
|
||||
* there is no chance to get the secure memory cleaned.
|
||||
*/
|
||||
void
|
||||
secmem_term()
|
||||
{
|
||||
|
Loading…
x
Reference in New Issue
Block a user