Creating a key bearing no user ID

Hubert Kario hka at
Mon Jan 23 18:52:20 CET 2012

On Monday 23 of January 2012 18:18:35 Robert J. Hansen wrote:
> On 1/23/12 11:34 AM, Hubert Kario wrote:
> > And there's a very good reson why you shouldn't be a fan of such
> > comparisions: Unlike physical security, properly implemented
> > cryptography is unbreakable at this time.
> This, of course, handwaves the fact that cryptography more or less
> *can't* be implemented properly.  As long as human beings are in the
> equation it will be misimplemented.  Consider the NSA's VENONA project,
> which was able to break one-time pads when the KGB had a braino and
> reused key material.
> We're not talking about some high school student sharing a Facebook
> password with someone.  This is the KGB, one of the most professional
> intelligence agencies that's ever existed.  KGB agents were highly
> motivated to practice good tradecraft, because if they didn't they might
> get shot in the back of the head in the basement of the Lyubyanka.  So
> even with the (substantial) organizational resources of the KGB, with
> the (significant) communications security training given to KGB field
> agents, with the (extreme) penalties for transgression, even then
> somebody was dumb enough to reuse a key pad.
> The lesson I take from this is that the phrase "properly implemented
> cryptography" is about as useful as talking about absolute zero.  It's
> useful to show what the limit is, but it can never be reached, and
> anyone who believes they are immune to this is the lawful prey of those
> who know otherwise.

I didn't claim that any crypto is properly implemented.

I did claim it is far easier to find unbreakable crypto than it is to create 
unbreakable physical security. If TLAs are involved, then still the first is 
only questionable while the second is simply imposible.

Also, your example is flawed: any security scheme can be only as good as the 

Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawerów 30/85
tel. +48 (22) 646-61-51, 646-74-24
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2346 bytes
Desc: not available
URL: </pipermail/attachments/20120123/7aecad9e/attachment.bin>

More information about the Gnupg-users mailing list