[cryptography] can the German government read PGP and ssh traffic?

ianG iang at iang.org
Mon Jun 11 02:43:35 EDT 2012


On 5/06/12 23:46 PM, Thierry Moreau wrote:
> Hi Peter,
>
> Replying on the thinking process, not on the fundamentals at this time
> (we seem to agree on the characteristics of PKC vs else).
>
> Peter Gutmann wrote:
>> Thierry Moreau <thierry.moreau at connotech.com> writes:
>>
>>> Unless automated SSH sessions are needed (which is a different problem
>>> space), the SSH session is directly controlled by a user. Then, the
>>> private
>>> key is stored encrypted on long term storage (swap space vulnerability
>>> remaining, admittedly) and in *plaintext*form*only*momentarily* for SSH
>>> handshake computations following a decryption password entered by the
>>> user.
>>
>> ...except that a user study a few years back ("Inocilating SSH Against
>> Address
>> Harvesting") found that two thirds of all SSH private keys were stored in
>> plaintext on disk. You need to look at what actually happens in
>> practice, not
>> what in theory should happen in an ideal world.
>>
>
> Agreeing about the survey findings, if we think towards a solution (or
> some form of improvements), we may focus our attention on the PKC
> characteristics benefiting to the one third of PKC users that are not
> that bad in private key protection.


The thinking process here seems to be back to front :)  We should be 
focusing our attention on the user base we've got, plain and simple. 
What do they do?  How are they likely to help (themselves/us/security) ? 
  Why don't they like our designs?

We shouldn't be targetting some group of users just because they happen 
to have heard&obeyed our crypto-religious dictat, even if it validates 
our scientific prowess and makes us feel good.  That way lies circular 
logic and ultimately irrelevance.  This is what happened to PKI -- they 
spent so much time instructing their users on the right way to secure 
the security model that they didn't notice that users went elsewhere.

Looking at the users we've got - yes, everyone (two thirds apparently) 
stores their SSH keys in plaintext.  That's because it works.  At some 
stage this weakness will cause a problem, and that's the time to have 
something ready to fix that.  (And yes, there are possibilities, they 
just need to automated.)  In the meantime, the SSH design has delivered 
a remarkable security product, and we didn't even need to encrypt the 
keys :)


>> In any case though you're completely missing the point of my argument
>> (as did
>> the previous poster), which is that a scary number of people follow the
>> thinking that "passwords are insecure, PKCs are secure, therefore
>> anything
>> that uses PKCs is magically made secure" even when it's quite
>> obviously not
>> secure at all. This is magical thinking, not any kind of reasoned
>> assessment
>> of security.
>>
>
> Agreeing that this magical thinking is indeed operative (not only in IT
> security, e.g. a Judge accepting blindly the conclusion of a forensic
> expert irrespective of arguments by the opposing party), the association
> you made with SSH (which is a neat PKC implementation devoid of PKI
> endless complexity) is what triggered my reaction. Would you extend the
> association to PGP usage?


Absolutely there is magic thinking in PGP, and it is one of the reasons 
it suffers.  PGP people try so hard to protect their keys that they 
don't notice people sliding away and going somewhere else.

The most likely alternative to super-duper security is no security. 
Giving this choice to users is about the worst design decision one can 
make.  K6, etc.


> Would you extend the association to Lotus
> Notes as another PKC user community (
> http://en.wikipedia.org/wiki/Lotus_Notes#Security )?
>
> The temptation to consider IT security "a done deal" exists with every
> mechanism, we should also agree on that.


Yep, definately :)

> Good IT security solutions based on PKC may exist despite of the
> temptation. I further opine that SSH using PKC may be part of reasonably
> good IT security solutions, and the temptation will still exist.


Temptation is the normal response for users coping with bad design choices.



iang



More information about the cryptography mailing list