[Standards-JIG] Re: The Great Encryption Debate
ian.paterson at clientside.co.uk
Tue Aug 9 16:42:07 UTC 2005
> The trouble I always run into when trying to come up with
> effortless security is the issue of private keys... The
> user won't have any security if he attempts to login from
> another machine.
Yes. The only 100% transparent solution is to encrypt it with a password
and keep it on the server.
I know passwords provide minimal security, but do we have a better
choice for Aunt Tillie?
Of course everyone else (all 0.1%) can still use USB keyfobs, and
hopefully she will too in the end (or an Iris scanner).
> Another problem is that this private data is at risk if the
> user does not know he should protect it (or does not know
> that he even has it!). For now, 99.9% of users can't handle
> private keys.
Even in the worst case, private keys can be encrypted with Aunt Tillie's
So we can design a system that protects her unless attackers discover
her password. Today she is completely unprotected. So we can at least
make her better off than she is now.
I'm not suggesting that we tell Aunt Tillie she is Safe. I just think we
have a responsibility to make her as safe as we can.
> The mechanism I would suggest would be for a private key to be stored
> on the server, symmetrically encrypted. When using a different
> machine, the user would enter their normal Jabber password (for the
> server) and their pass-phrase for encryption. The (encrypted)
> private key would then be downloaded and decrypted on the client.
> Not quite seamless, but it is relatively easy to use.
> The only problem with this is that it is vulnerable
> to an off-line attack if the server is compromised.
> Of course the ideal solution would be for everyone to use a
> USB cryptography device, but that's not entirely feasible...
FYI, the client I use makes this 100% seamless. When people use it to
register a new account with a server the client sends a SHA256 hash of
the password they chose (instead of the plaintext password) to the
server. The client uses this hash instead of the password whenever the
user goes online. This allows the client to use a different keyed hash
(HMAC) of the *same* password to symmetrically encrypt data stored
either locally or on the server (the server cannot decrypt the data).
The only disadvantage of this approach is that the user has to type a
different (longer) password if they ever use another client (not usually
necessary since the Web client is available everywhere).
Passwords are not Secure, but they are more secure than nothing for Aunt
More information about the Standards