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