Encryption validation issues

[autophage]

I see that if my message isn't sent due to an encryption failure (I provided a crypto key of '123456' and a destruct key of '123456', and it told me that I needed to make sure my crypto key was long enough... either the length detection algorithm is wrong or the error shown when both keys are the same is wrong, I'm not sure which) then when you are allowed to rectify your errors, your message is shown already encrypted. That's cool, except for the fact that (presumably) if I then supply a valid encryption key, the thing that gets encrypted is the already-encrypted message... thus, gibberish. By the way, there's a mismatch - the page SAYS your crypto key must be 6+ characters, but instead you get a failure if it's 6 or 7, and that error says that it must be 8+.

[radiosilence]

This is fixed. Might reduce it to 6, though.

[Natanael90]

I'd suggest you do NOT reduce it! 8 char passwords can be bruteforced easily! 12 should be minimum for security.

[radiosilence]

Fair enough, surely using a stretched hash for PBKDF means that bruting would much, much harder?

[Natanael90]

Stretched hash? Well, only the entropy bits of the input (the password) is what decides how easy it is to bruteforce the key when the algorithm is known. Just use SHA256 on the pass to make a key, and make sure that nobody use stuff from wordbooks as their password.

[radiosilence]

But surely making it slow to hash the passphrase means it would take longer to brute? Especially if it's salted On Jun 7, 2011 7:39 PM, "Natanael90" < reply@reply.github.com> wrote:

Stretched hash? Well, only the entropy bits of the input (the password) is what decides how easy it is to bruteforce the key when the algorithm is known. Just use SHA256 on the pass to make a key, and make sure that nobody use stuff from wordbooks as their password.

Reply to this email directly or view it on GitHub: https://github.com/radiosilence/wire/issues/11#comment_1320062

[Natanael90]

Sure, nothing prevents you from using 1'000'000 iterations of SHA256 to slow down bruteforce. Except that people who are using the site on their phones will nag at you.

[radiosilence]

I'll have to do some speed tests, but surely every iteration slows down their brute-forcing exponentially? I'm using 2^10 iterations of whirlpool at present, which has got to slow down brute force more?

Say there were 40,000 possible characters, and t is the time to break one hash divided by the number of processes.

(40 000^8) * (2^10) = (6.7108864 × 10^39)t for my current scheme with 8 characters (40 000^12) * 1 = (1.6777216 × 10^55)t for your proposed method.

Looks like I'm increasing the passphrase length :)

Say people only used 0-9a-zA-Z, however...

(62^8)_(2^10) = (2.23580268 × 10^17)t (62^12)_1 = (3.22626676 × 10^21)t

Which just confirms you're right, really.

I wonder how many t it would be for a combination.... (40 000^12) * (2^10) = (1.71798692 × 10^58)t ...crikey.

So with your scheme (12 character passphrase, one iteration SHA-256), say they had 256 GPUs cracking at 100,000,000 hashes per second, it would take:

(((62^12) * 1) * ((1 / 100 000 000) / 256)) / (3600 * 24 * 356) = 4 097.28872 years. I like those odds.

[radiosilence]

Natanael90 - what do you think about this? http://bitwiseshiftleft.github.com/sjcl/

[Natanael90]

Looks good. I guess that should be secure. Also, don't forget to protect the site against XSS and SQL exploits, etc!

[Natanael90]

BTW, iterations do NOT increase the difficulty (edited) exponentially, only increased password character length does (and some other things too, mostly related to deep crypto details).

Edit: 1000 iterations, 0-9 numbers as characters (10 different chars), 12 char length, 50 000 tested passwords per second: (10^12)_1000/50000 = numbers of seconds to crack it (2.5_10^9, if I got it right). Edit 2: Try to alter these numbers in the calculations freely to see what produces the best numbers, both user performance wise (for people on phones) and security wise.

[radiosilence]

Indeed, SQL isn't a problem, and Flask escapes stuff by default. There's also a handy CSRF module I'll configure before release. It isn't implausible that someone's identity could be compromised by a forged request that sends a message to a specific account and logs the IP.

[radiosilence]

I've started work on end to end encryption here:

https://github.com/radiosilence/wire/tree/jscrypt

What are your opinions on the UX of the encryption? Currently I have the JavaScript adding a box below the message to enter an encryption key. They then click "Encrypt" and if the key is long enough, the message box is replaced with a box that simply says "Encrypted message"

[radiosilence]

Check it out! I've implemented end to end encryption using stanford library!

Log in and check this thread: http://wire.0xf.nl/thread/18

key is "iliketurtles"

[radiosilence]

I'm using a minimum 12 character passphrase with 10,000 iterations of SHA-256. So it should hold.

[Natanael90]

I've tested that page now, it works well. Going to try it on my phone sometime later, I'll report on performance. (Although I do not have the knowledge or skill needed to review the security of it.)

Edit: I can see that you are also using JS from sources outside your domain on that page. That is VERY unwise, no matter how much you trust those sites. If any of those don't use SSL, the security is essentially destroyed as soon as the user enters his password. Please don't include ANY content from 3rd party domains on the same pages that JS crypto is used on!

[radiosilence]

Phone performance was pretty slow. Think 1000 iterations (instead of 10,000) is a good idea? James

On 16 June 2011 10:49, Natanael90 < reply@reply.github.com>wrote:

I've tested that page now, it works well. Going to try it on my phone sometime later, I'll report on performance. (Although I do not have the knowledge or skill needed to review the security of it.)

Reply to this email directly or view it on GitHub: https://github.com/radiosilence/wire/issues/11#issuecomment-1379903

[Natanael90]

Did you try it on a phone? Please tell which. I have an SGS and a Spica, I can try it on both later.

Decreasing the iterations by a factor of 10 (10 000/1 000) does decrease the time to break it by as much, but adding a single character to the password length makes up for it (another (possible passwords)(26+26+10+special characters), makes the total time longer since that's essentially (brute force time)/10(26+26+10+special characters).

While computers get faster and some units won't speed up at the same pace (such as my Spica that ain't gonna get faster by itself), only longer passwords will be a working secure solution. Or we'll have to discriminate against slow devices.

[radiosilence]

That makes sense, I think I'll pop it down to 1,000 and see how fast it it.