Hi Michael, Thanks for the feedback! Responses inline.
The simple, usable interface is really cool, I love it. > Obligatory crypto bikeshedding: > An 80-bit hash isn't long enough to prevent a second-preimage attack > by a well-funded adversary, but it's too long for users to memorise or > manually enter addresses. Perhaps a longer hash would be better? I originally had 160-bit hashes, but that made for very long email addresses. The hash format (first 80 bits of SHA-1, encoded base32) is the same as Onion URLs use. How do they avoid preimage attacks? (I thought generating 2^80 keypairs and checking each one to see if the public key matches was simply too much work, maybe I'm wrong though.) When storing the private key on the server, you encrypt the private > key with a symmetric key derived from the user's passphrase. The > server could use a dictionary attack with rainbow tables to decrypt > the private key. You should use random salt and a key derivation > function designed for deriving keys from passwords, such as PBKDF2 or > scrypt, to derive the symmetric key. Yes, I'll try that now, thanks! How exactly is the symmetric key used to encrypt the private key? What > block cipher mode do you use? Is there authentication as well as > encryption? (Currently I'm using the first 128 bits of a SHA hash as the key, then AES-128 symmetric encryption.) I have authentication as well as encryption. (I don't rely on the authentication for message secrecy. It's just so that normal, non-NSA adversaries can't download your email and attempt to crack the encryption. Also so that normal adversaries can't get meta-info such as the number of unread emails you have.) SHA1( "1" || passphrase) -> authentication token, server sees this SHA1( "2" || passphrase) -> used to encrypt the private key, server never sees this ... after implementing your suggestion, it will be PBKDF2 instead, and I'll generate a random salt for each user. (That way, an attacker can only try to brute-force one account at a time, instead of all of them.) Thanks for the feedback, DC On Fri, Aug 23, 2013 at 6:41 AM, Michael Rogers <mich...@briarproject.org>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 23/08/13 09:53, DC wrote: > > One difficult problem in public-key encryption is key exchange: how > > to get a recipient's public key and know it's really theirs. My > > plan is to make make your email the hash of your public key. For > > example, my address is *nqkgpx6bqscsl...@scramble.io (I borrowed > > this idea from Tor Hidden Services.) > > Hi DC, > > The simple, usable interface is really cool, I love it. > > Obligatory crypto bikeshedding: > > An 80-bit hash isn't long enough to prevent a second-preimage attack > by a well-funded adversary, but it's too long for users to memorise or > manually enter addresses. Perhaps a longer hash would be better? > > When storing the private key on the server, you encrypt the private > key with a symmetric key derived from the user's passphrase. The > server could use a dictionary attack with rainbow tables to decrypt > the private key. You should use random salt and a key derivation > function designed for deriving keys from passwords, such as PBKDF2 or > scrypt, to derive the symmetric key. > > How exactly is the symmetric key used to encrypt the private key? What > block cipher mode do you use? Is there authentication as well as > encryption? > > Cheers, > Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJSF2aRAAoJEBEET9GfxSfMgikIAJeU459ig7XNufyyIuO9BAUF > /J0pd0g+pPspWoHvby8W6A1g0ZbTsGBVMbuEOx9BKuSA1FY1skLGZ+Ua6LZUX1ZQ > uLNHFs5+kP5lNelYw2oZp/QI63HExAgjMzrFryRl9/pC3Q49N/jdlN+Ssh5YHZ47 > LhPNOtgZP4jTq3//T11f7T3fQ09PALrpgREGagfybfP598sEmLuQ2iA2kZNYWO/9 > vSnYnQBaWXtmissF0znaOPELYlGGW/TMZMGWxSJ748pjpWB6fZR3/IlRXTaMrp76 > 8MVhjQP6MCi5AJpsDserQWscTaQyDTP/g7ZVGshreOFelPGjB4QwhFlBfjBEzr0= > =k3QU > -----END PGP SIGNATURE----- >
-- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
