Mailing List Archive

On Fri, Oct 30, 1998 at 09:02:40PM +0100, Werner Koch wrote:
> > I have not looked into source, maybe you just need to use clever *search*
> > algorithms?
>
> There is no source yet. You suggest that I should use a flat file
> and grep through it for the user name - hmmm, that's easy.
Oops. I thought that you were speaking about some existing stuff.

As you said the only thing that can be used as key in your gdbm file is key id
(which is unique by definition) or fingerprint. All other information will be
got through scanning and search. Correct? So you will need an advanced search
algorithm anyway.

--
Mike

wk@isil.d.shuttle.de (Werner Koch) writes:
> To distribute a large keyring over a couple of disks I think it will
> also be a good idea to use some bits from the keyring to index a file.
> Using symlinks for the gdbm files should give an admin the
> possibility to put the files on different disk.

This is only marginally related, but if you're playing with the keyring code
anyway.. I've been pondering other (read "more secure") ways to store and
retrieve the secret key material. One thing that might help open up more
mechanisms would be to add a hook to get secret keyring data by running a
program and simply gathering stdout. You could pass the keyid to the program
and it would return a (possibly armored) private keyblock. GPG uses the data
and then throws it out. I'm thinking of something like a Pilot attached to a
serial port, and then the program in question would send a request for the key
to the pilot, which would just dump some text back through the serial port. I
think this could be done with a script around the existing pilot-xfer tools in
a simple memo without having to write anything particularly clever. Anything
to avoid keeping my private keys on my system at work. And if the passphrase
could still be used on a key stored/transmitted in such a manner, all the
better. Still two factors ("thing you have" and "thing you know"), but the
"thing you have" is now something small you can take home with you at night.
A simple nvram iButton just containing data would be even smaller.

I think the ssh-style encryption-agent is the long-term way to go, but a hook
for something like this might be convenient. Something like
"add-secret-keyring-program /path/bin/program". If there were multiple
entries, call each one in order until the key is returned.

cheers,
-Brian
warner@lothar.com

Moin,

Am / On 02 Nov 1998 21:14:54 -0800, Brian Warner <warner@lothar.com>
wrote:

>I've been pondering other (read "more secure") ways to store and
>retrieve the secret key material. One thing that might help open up more
>mechanisms would be to add a hook to get secret keyring data by running a
>program and simply gathering stdout. You could pass the keyid to the program
>and it would return a (possibly armored) private keyblock. GPG uses the data
>and then throws it out. I'm thinking of something like a Pilot attached to a
>serial port, and then the program in question would send a request for the key
>to the pilot, which would just dump some text back through the serial port.

Good idea to keep the secretkey in a box with you. Palm Pilot is
widely spread. And someday the pilot can speak to every computer via
IrDA.
But i do not want to transmit my secret keys to any computer i work
with. Maybe his OS is tampered with a trojan or sth.
So the solution would be a gnupg for pilot. AFAIK there is a gcc for
pilot. This would be a little slow, but it would be very handy ...

comments?


Gruss,
Walter
--
Walter Koch Hochdahl am Neandertal
walterk@mail.dip.de ham:dg9ep@db0iz
http://home.pages.de/~dg9ep/ qrv:db0iz-9

At around Sun, 08 Nov 1998 19:42:53 +0100,
walterk@dip.de (Walter Koch) may have mentioned:

> Moin,
>
> Am / On 02 Nov 1998 21:14:54 -0800, Brian Warner <warner@lothar.com>
> wrote:
>
> >I've been pondering other (read "more secure") ways to store and
> >retrieve the secret key material. One thing that might help open up more
> >mechanisms would be to add a hook to get secret keyring data by running a
> >program and simply gathering stdout. You could pass the keyid to the program
> >and it would return a (possibly armored) private keyblock. GPG uses the data
> >and then throws it out. I'm thinking of something like a Pilot attached to a
> >serial port, and then the program in question would send a request for the key
> >to the pilot, which would just dump some text back through the serial port.
>
> Good idea to keep the secretkey in a box with you. Palm Pilot is
> widely spread. And someday the pilot can speak to every computer via
> IrDA.
> But i do not want to transmit my secret keys to any computer i work
> with. Maybe his OS is tampered with a trojan or sth.
> So the solution would be a gnupg for pilot. AFAIK there is a gcc for
> pilot. This would be a little slow, but it would be very handy ...
>
> comments?

need to be careful of 'syncing' your palm device as that may end up
depositing secret key information on a networked computer (or even
non-networked computer which isn't guarded most/all of the time).

i don't suppose there is any hardware/software support in the palm
device for 'protecting' data from being synced? (but then, what if
the data on your pilot gets wiped? -- there should be a backup on
some other media in a safe somewhere? -- and, do you trust potential
syncing protection mechanisms that may end up being non-open-source?)

walterk@dip.de (Walter Koch) writes:
WK> Good idea to keep the secretkey in a box with you. Palm Pilot is
WK> widely spread. And someday the pilot can speak to every computer via
WK> IrDA.
WK> But i do not want to transmit my secret keys to any computer i work
WK> with. Maybe his OS is tampered with a trojan or sth.
WK> So the solution would be a gnupg for pilot. AFAIK there is a gcc for
WK> pilot. This would be a little slow, but it would be very handy ...
WK>
WK> comments?

Actually, there's already some form of OpenPGP for the pilot; somebody on the
working group mailing list hacked something together with the SSLeay pilot
library. Haven't played with it at all, though. I think replay.com has it in a
file called "palmopgp12.tgz". Sounded like some good ideas from what I read:
keys were kept in address book records, so you could give your public key to
someone by just "beaming" your own record to them.

I was thinking about some intermediate step between A) doing everything on the
computer and B) doing everything on the Pilot. Let's call the pilot the
encryption agent (since it could be an iButton or a more-secure laptop or any
device capable of doing some math and communicating with the main "computer"
but which is smaller and therefore considered more secure). For signatures,
you send the message hash over to the agent and it sends back the signature
packet. For decryption, you send the encrypted session key packet to the agent
and it sends back the decrypted session key. A tradeoff of convenience (and
speed: the Pilot is not very fast, the iButton even slower) for total
security. Actually the security of doing everything on the agent isn't total:
you then have to worry about being tricked into sending/fetching your document
from something that isn't a agent (send the message to /dev/ttyS0 for
decryption, and something comes back, but your agent was on /dev/ttyS1.. who
sent that message? how do you verify that?).

If only secret key operations take place on the agent: what could be
compromised? (suggestions on this kind of analysis are more than welcome: I'm
just winging it here):

threat: somebody replaces your agent with their fake program (attempt to trick
the computer by spoofing the agent)

compromise: decryption: you send an encrypted session key to them, which they
can't do anything with anyway (it was part of the original message, which
an eavesdropper could get without the agent).

compromise: signature: you send a message hash to them, which doesn't tell
them anything useful about the message. They can sign it with the wrong key,
which would be annoying (so you must verify the signature right away), but
they can't fake a good sig.


threat: somebody steals your agent or subjects your agent to a different
program (attempt to trick the agent by spoofing the computer)

compromise: more serious. You'd need some kind of session verification: the
computer-side GPG sends a request to the agent and also computes a hash of the
request and displays it. The agent (if possible) displays the same hash and
requests verification from the user (out of band) before performing the
requested encryption. This won't help for an iButton: but since they can be
considered "tamperproof" you could probably have the iButton have a
private/public key and a list of public keys that are allowed to make
requests. The request could be encrypted (preventing anyone from faking the
agent) and the request could be signed (preventing anyone from faking the
computer). But then the agent would be doing at least two operations.. starts
to sound ugly.

threat: somebody listens to the communication between your agent and the
computer doing the rest of the encryption/decryption.

compromise: decryption: the eavesdropper gets the decrypted session key. If
they got the original encrypted message too then they can decrypt that one
message. The compromise is limited to that one message.

compromise: signature: they can see the signed message hash, but that is put
into the final message anyway. If the message is then encrypted they might
have a little bit of known-plaintext to work with (encryption occurs after
signatures, right?).

sen_ml@eccosys.com writes
SEN>need to be careful of 'syncing' your palm device as that may end up
SEN>depositing secret key information on a networked computer (or even
SEN>non-networked computer which isn't guarded most/all of the time).
SEN>
SEN>i don't suppose there is any hardware/software support in the palm
SEN>device for 'protecting' data from being synced? (but then, what if
SEN>the data on your pilot gets wiped? -- there should be a backup on
SEN>some other media in a safe somewhere? -- and, do you trust potential
SEN>syncing protection mechanisms that may end up being non-open-source?)

There is a flag for each database (dmHdrAttrBackup) that says "back me up with
the default conduit [straight dump of the database structure] if no
application-specific conduit is available". I believe that if you leave this
flag off, the standard HotSync program will not back up the database. I think
the common unix backup utility (pilot-xfer) ignores the flag and copies
everything, and a malicious program can use RPC calls to do whatever it wants.
So be careful what you plug into that Pilot when you hit "HotSync"... :)


Anyway, I think this might be a useful thing. It might let me use my real
private key at work instead of having separate work and home keys, in which
anyone with root at work could spoof my work identity.

Thoughts?

-Brian
warner@lothar.com

sen_ml@eccosys.com writes:

> the data on your pilot gets wiped? -- there should be a backup on
> some other media in a safe somewhere? -- and, do you trust potential

I do this with my keys:

gpg --export-secret-keys --armor | lpr

and deposit it together with the revocation certificates in a safe
(but w/o the passphrase written down).

> syncing protection mechanisms that may end up being non-open-source?)

I think Walter speaks about a special syncing mechanism for GnuPG.
Walter are you going to buy a PalmPilot?

Werner

On Sun, 8 Nov 1998, Walter Koch wrote:

> So the solution would be a gnupg for pilot. AFAIK there is a gcc for
> pilot. This would be a little slow, but it would be very handy ...

Hmm. I'm owning a Psion Series5. I thought a year ago before I know from
gnupg about a pgp tool for Psion...

But their is no public available 'C' development environment for the
Psion. No gcc available, IMHO. You must buy a compiler. :-(

But anyway, it's a nice idea...


cu

Michael Roth

Michael Roth <mroth@nessie.de> writes:

> But their is no public available 'C' development environment for the
> Psion. No gcc available, IMHO. You must buy a compiler. :-(

What kind of CPU? gcc supports nearly every CPU.

> Michael Roth <mroth@nessie.de> writes:
>
> > But their is no public available 'C' development environment for the
> > Psion. No gcc available, IMHO. You must buy a compiler. :-(
>
> What kind of CPU? gcc supports nearly every CPU.

ARM. I don't have the development kit for my Psion S5 either, but
I seem to remember someone saying that it used gcc. What you're
paying for is the libraries and documentation, and the stuff to
get your code from the development PC into the Psion to run. I think.
The ARM code generator for gcc was originally developed for other
(desktop) platforms.

--
David Pick

On Tue, 10 Nov 1998, Werner Koch wrote:

> > But their is no public available 'C' development environment for the
> > Psion. No gcc available, IMHO. You must buy a compiler. :-(
>
> What kind of CPU? gcc supports nearly every CPU.

The CPU is an ARM 7100 clocked with about 19MHz. The operating system is
called 'EPOC32'.


cu

Michael Roth