[PATCH] Distant signatures
Petr Baudis
pasky at pasky.ji.cz
Wed Jul 3 12:06:02 CEST 2002
Dear diary, on Wed, Jul 03, 2002 at 09:37:58AM CEST, I got a letter,
where Werner Koch <wk at gnupg.org> told me, that...
> On Wed, 3 Jul 2002 06:16:42 +0200, Marcus Brinkmann said:
>
> > If you don't trust server A, how can you be sure that the generated hash is
> > really the one you want to sign? The problem with a detached signature like
> > the one you described is that you don't know what you sign if you can't
> > verify the hash on the trusted system. I think this approach is
> > fundamentally flawed.
>
> There are situations where this can really come handy and I have
> thought about this for a while: I keep my certification key (5B0358a2)
> offline and use it only on a floppy-only-connected laptop. From time
> to time some folks send me a challenge I should sign; there is no
> standard format for it and thus I have to go into great length to
> process the mail offline. It would be far easier to create the
> required hash on my normal machine and transfer this hash along with
> the other keys I am going to sign to the laptop, later on pasting the
> created signature back into the response.
>
> Similar to Petr's requirement, one might want to sign a new package
> which does not fit onto a floppy (think of gcc) but still keep the
> signing key at a safer place. Yes, this does not make the signature
> in anyway safer but it protect the signing key better against
> misuse.
That's it :). I think compromise of the hash is still "better" than
compromise of the key. And sometimes it's not so tragical. Obviously, the user
should be warned appropriatelly.
> > In real world, your security requirements might not be as strict as
> > described above. Still, I think this feature is somewhat dangerous.
>
> There are also a lot of other dangerous features which could do a lot
> of harm if used by the unaware, so another expert option would be
> okay. We might implement this later but not for 1.2
If noone will ask me to maintain the patch.. :) I'll obviously welcome if
this feature would be integrated ASAP, as I could upgrade my gnupgs normally
then, and more people possibly missing this feature would be made happy.
Well, apparently something like
if( mc == 1 )
fprintf(stderr,
"WARNING! You must be aware that the hash being exported MAY be COMPROMISED and\n"
"invalid, if you doesn't trust this machine. Handle it with extremely care and\n"
"supsicion.");
else if( mc == 2 )
fprintf(stderr,
"WARNING! If the hash being imported was exported on untrusted machine, there's\n"
"no guarantee that this hash is valid; it MAY be COMPROMISED and invalid! Handle\n"
"signatures created from imported hashes with extremely care and suspicion.");
is certainly needed.
What maybe needs to be done (and I probably won't do it anymore):
- importing armored hashes
- possibly generating "hash packets"
- not saving hashes to .sig/.asc but probably .hsh
- signatures from file.hsh to file.*, not file.hsh.*
- endianity issues in *_{import,export}().
- better options description
- options documentation
- support for specifying hash type.. (maybe we can at least support
opt.default_digest).
- nothing else comes to my mind..
Anyway, I used this patch extensively this morning and it appears that it
works fine (when used on machines with same endianity).
Kind regards,
--
Petr "Pasky" Baudis
* ELinks maintainer * IPv6 guy (XS26 co-coordinator)
* IRCnet operator * FreeCiv AI occassional hacker
.
"Capitalism is the extraordinary belief that the nastiest of men,
for the nastiest of reasons, will somehow work for the benefit of
us all." -- John Maynard Keynes
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/
More information about the Gnupg-devel
mailing list