See ChangeLog: Tue Aug 31 17:20:44 CEST 1999 Werner Koch
[gnupg.git] / THOUGHTS
1
2
3 EGD
4 ====
5 Oh, and on embedding egd into the gpg package: I think if you just unpack it
6 into, say, util/egd/* then you can put something like this into configure.in:
7
8 AC_CHECK_PROG(perl_present, perl, true, false)
9 if $perl_present; then
10  AC_PATH_PROG(PERL, perl)
11  (cd util/egd; $PERL Makefile.PL FULLPERL=$PERL INSTALLBIN=$sbindir)
12 fi
13 AM_CONDITIONAL(WITH_EGD, $perl_present)
14
15 and add util/egd to the top-level Makefile directory list inside a WITH_EGD
16 conditional.
17
18     * What shall we do if we have a valid subkey revocation certificate
19       but no subkey binding?  Is this a valid but revoked key?
20
21     * use a mmaped file for secure memory if mlock does not work and
22       make sure that this file is always wiped out.  Is this really
23       more secure than swapping out to the swap disk?  I don't
24       believe so because if an attacker has access to the physical
25       box (and he needs this to look at the swap area) he can also
26       leave a Trojan horse which is far more easier than to analyze
27       memory dumps.  Question:  Is it possible that a Unix pages
28       an old (left over by some other process) swap page in for
29       another process - this should be considered a serious design
30       flow/bug.
31
32 Date: Mon, 4 Jan 1999 19:34:29 -0800 (PST)
33 From: Matthew Skala <mskala@ansuz.sooke.bc.ca>
34
35 - Signing with an expired key doesn't work by default, does work with a
36   special option.
37 - Verifying a signature that appears to have been made by an expired key
38   after its expiry date but is otherwise good reports the signature as BAD,
39   preferably with a message indicating that it's a key-expiry problem rather
40   than a cryptographically bad signature.
41 - Verifying a signature from a key that is now expired, where the
42   signature was made before the expiry date, reports the signature as
43   GOOD, possibly with a warning that the key has since expired.
44 - Encrypting to an expired key doesn't work by default, does work with a
45   special option.
46 - Decrypting always works, if you have the appropriate secret key and
47   passphrase.
48
49
50
51 -----BEGIN PGP SIGNED MESSAGE-----
52 Hash: SHA1
53
54 Hi Werner..
55
56 I was looking at some of the PROJECTS items in the recent gpg CVS and wanted
57 to comment on one of them:
58
59   * Add a way to override the current cipher/md implementations
60     by others (using extensions)
61
62 As you know I've been thinking about how to use a PalmPilot or an iButton in
63 some useful way in GPG. The two things that seem reasonable are:
64  1) keep the secret key in the device, only transferring it to the host
65     computer for the duration of the secret-key operation (sign or decrypt).
66     The key is never kept on disk, only in RAM. This removes the chance that
67     casual snooping on your office workstation will reveal your key (it
68     doesn't help against an active attack, but the attacker must leave a
69     tampered version of GPG around or otherwise get their code to run while
70     the key-storage device is attached to attack the key)
71  2) perform the secret-key operation on the device, so the secret key never
72     leaves the confines of that device. There are still attacks possible,
73     based upon talking to the device while it is connected and trying to
74     convince the device (and possibly the user) that it is the real GPG,
75     but in general this protects the key pretty strongly. Any individual
76     message is still vulnerable, but that's a tradeoff of the convenience of
77     composing that message on a full-sized screen+keyboard (plus the added
78     speed of encryption) vs. the security of writing the message on a
79     secure device.
80
81 I think there are a variety of ways of implementing these things, but a few
82 extension mechanisms in GPG should be enough to try various ways later on.
83
84 1) pass an argument string to loadable extension modules (maybe
85     gpg --load-extension foofish=arg1,arg2,arg3 ?)
86 2) allow multiple instances of the same extension module (presumably with
87    different arguments)
88 3) allow extension modules to use stdin/stdout/stderr as normal (probably
89    already in there), for giving feedback to the user, or possibly asking them
90    for a password of some sort
91 4) have an extension to provide secret keys:
92
93    It looks like most of the hooks for this are already in place, it just
94    needs an extension module which can register itself as a keyblock resource.
95
96    I'm thinking of a module for this that is given an external program name as
97    an argument. When the keyblock resource is asked to enumerate its keys, it
98    runs the external program (first with a "0" argument, then a "1", and so on
99    until the program reports that no more keys are available). The external
100    program returns one (possibly armored) secret key block each time. The
101    program might have some kind of special protocol to talk to the storage
102    device.  One thing that comes to mind is to simply include a random number
103    in the message sent over the serial port: the program would display this
104    number, the Pilot at the other end would display the number it receives, if
105    the user sees that both are the same they instruct the Pilot to release the
106    key, as basic protection against someone else asking for the key while it
107    is attached. More sophisticated schemes are possible depending upon how
108    much processing power and IO is available on the device. But the same
109    extension module should be able to handle as complex a scheme as one could
110    wish.
111
112    The current keyblock-resource interface would work fine, although it
113    might be more convenient if a resource could be asked for a key by id
114    instead of enumerating all of them and then searching through the resulting
115    list for a match. A module that provided public keys would have to work this
116    way (imagine a module that could automatically do an http fetch for a
117    particular key.. easily-added automatic key fetching). Without that ability
118    to fetch by id (which would require it to fall back to the other keyblock
119    resources if it failed), the user's device might be asked to release the
120    key even though some other secret key was the one needed.
121
122
123 5) have an extension to perform a secret-key operation without the actual
124    secret key material
125
126  basically something to indicate that any decrypt or sign operations that
127  occur for a specific keyid should call the extension module instead. The
128  secret key would not be extracted (it wouldn't be available anyway). The
129  module is given the keyid and the MPI of the block it is supposed to sign
130  or decrypt.
131
132  The module could then run an external program to do the operation. I'm
133  imagining a Pilot program which receives the data, asks the user if it can go
134  along with the operation (after displaying a hash of the request, which is
135  also displayed by the extension module's program to make sure the Pilot is
136  being asked to do the right operation), performs the signature or decryption,
137  then returns the data. This protocol could be made arbitrarily complex, with
138  a D-H key to encrypt the link, and both sides signing requests to
139  authenticate one to the other (although this transforms the the problem of
140  getting your secret key off your office workstation into the problem of
141  your workstation holding a key tells your Pilot that it is allowed to perform
142  the secret key operation, and if someone gets a hold of that key they may
143  be able to trick your pilot [plugged in somewhere else] to do the same thing
144  for them).
145
146  This is basically red/black separation, with the Pilot or iButton having the
147  perimeter beyond which the red data doesn't pass. Better than the secret-key
148  storage device but requires a lot more power on the device (the new iButtons
149  with the exponentiator could do it, but it would take way too much code space
150  on the old ones, although they would be fine for just carrying the keys).
151
152 The signature code might need to be extended to verify the signature you just
153 made, since an active intruder pretending to the the Pilot wouldn't be able to
154 make a valid signature (but they might sign your message with a different key
155 just to be annoying).
156
157 Anyway, just wanted to share my thoughts on some possibilities. I've been
158 carrying this little Java iButton on my keyring for months now, looking for
159 something cool to do with it, and I think that secure storage for my GPG key
160 would be just the right application.
161
162 cheers,
163  -Brian
164
165 -----BEGIN PGP SIGNATURE-----
166 Version: GnuPG v0.4.5 (GNU/Linux)
167 Comment: For info finger gcrypt@ftp.guug.de
168
169 iD8DBQE2c5oZkDmgv9E5zEwRArAwAKDWV5fpTtbGPiMPgl2Bpp0gvhbfQgCgzJuY
170 AmIQTk4s62/y2zMAHDdOzK0=
171 =jr7m
172 -----END PGP SIGNATURE-----
173
174
175
176 About a new Keyserver  (discussion with Allan Clark <allanc@sco.com>):
177 =====================
178
179 Some ideas:
180
181 o  the KS should verify signatures and only accept those
182    which are good.
183
184 o  Keep a blacklist of known bad signatures to minimize
185    the time needed to check them
186
187 o  Should be fast - I currently designing a new storage
188    system called keybox which takes advantage of the fact
189    that the keyID is highly random and can be directly be
190    used as a hash value and this keyID is (for v4 keys)
191    part of the fingerprint: So it is possible to use the
192    fingerprint as key but do an lookup by the keyID.
193
194 o  To be used as the "public keyring" in a LAN so that there
195    is no need to keep one on every machine.
196
197 o  Allow more that one file for key storage.
198
199 o  Use the HKS protocol and enhance it in a way that binary
200    keyrings can be transmitted.  (I already wrote some
201    http server and client code which can be used for this)
202    And extend it to allow reuse of a connection.
203
204 o  Keep a checksum (hash) of the entire keyblock so that a
205    client can easy check whether this keyblock has changed.
206    (keyblock = the entire key with all certificates etc.)
207    Transmitted in the HEAD info.
208
209 o  Allow efficient propagation of new keys and revocation
210    certificates.
211
212
213 Probably more things but this keyserver is not a goal for the
214 1.0 release. Someone should be able to fix some of the limitations
215 of the existing key servers (I think they bail out on some rfc2440
216 packet formats).
217
218
219 DJGPP
220 =====
221 Don't use symlinks but try to do the preprocessing in the config-links script.
222 DJPGG has problems to distinguish betwen .s and .S becaus the FAT filesystem
223 is not case sensitive (Mark Elbrecht).
224
225
226 Special procmail addresses
227 ==========================
228   * foo+bar@example.net:  Try to match the address without the "+bar".
229     Should be done by the MUA, but maybe we can do this.
230
231
232 Suggested things which I will not do:
233 =====================================
234   * Let take --help an option to select some topics.
235     Using grep is much easier
236
237