Checking key server response against the request parameters

[Stefan Tomanek]

Dies schrieb John Clizbe (John at enigmail.net):

> It looks like you are working from a solution back to a problem instead of
> from a problem to a solution.
> 
> Before you need this solution, you need to be able to fetch a secret key from
> a keyserver, and before you can do that, you need a keyserver that will accept
> and store a secret key. None that I know of will (PKS, CKS, ONAK, OpenPKSd,
> SKS, LDAP implementations).

And it looks like you are working under the assumption that a) the keyserver is
playing nice with you and b) you are actually talking to the keyserver you
specified. Both assumptions are completely bogus, considering that is trivial
to mount an man-in-the-middle attack against keyserver traffic.

No real keyserver will store secret keys, at least I hope so. But I've written
a PoC keyserver proxy that will happily put himself between a real keyserver
and the client - and believe me, this one *does* deliver secret keys.

Well, to be honest, I have to "mask" the secret key, since gpg in fact does
reject data starting with "BEGIN PGP PRIVATE KEY DATA", but s/PRIVATE/PUBLIC/
does the trick.  Oddly enough, gpg then only imports the secret key, not the
public part - weird.

Never, ever, trust incoming data. 
-- 
if(is) - Institut für Internet-Sicherheit
Westfälische Hochschule, Gelsenkirchen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: </pipermail/attachments/20130916/fcfbf53a/attachment.sig>