[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