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.mor...@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
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Reply via email to