Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Good and Bad Crypto

Anyone following the AeroFS thread knows I just wrote a bunch about good and bad crypto, with particular emphasis that the quality of crypto is not strongly correlated to the code being open or closed source.

Speaking of which, this is something I put some work into recently, that I'm proud of and think people should be thinking about more:

What I have written is not fit for general consumption.  It's a proof of concept, and demonstration that the principle is sound.  Chances are, it's probably actually secure (I think so, and I'm pretty good at this) but it hasn't been widely reviewed, and a lot of the decisions are currently hard-coded into it (for example, hard-coded to use SHA-256 and ECDH, which should be optional.)  It seems the next step needs to be drafting a standard, and gaining adoption from projects such as Chrome, Firefox, etc.

Long and short of it:  As we've seen, both because of heartbleed and all the other security bugs in crypto libraries, and all the stuff I just wrote about in the AeroFS thread, you can't necessarily assume your communications are secure, even over a secure SSL/TLS channel.

Never send your password to anyone.  Not even a secure trusted server on a secure communication channel.  This logically reduces to only 2 possible solutions:  You must either use a clientside random secret manager, which requires that you transport it around with you somehow, or you use authentication techniques such as asymmetric algorithms, to verify your identity without exposing information about your secret.

Instead of sending your secret to the server, use your public knowledge of the server, combined with your username and password, AND WORKFACTOR, to deterministically generate a public/private keypair which is unique to that username, on that server, with that password.  Only send the public component.  *Usually* your communication channel will actually be secure, but even if it does get compromised by something such as heartbleed, then the attacker only gains knowledge of your public key, and they can *neither* impersonate you at the compromised server, nor anywhere else.

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /