Encryption Help

[Jeff_Mott]

@DrQuincy

Sort of off-topic but do you think salts should be generated from a cryptographically secure source? I personally don’t think they should, they should just be unique for each password as they are there to prevent rainbow tables.

I absolutely agree with both you and the ircmaxwell quote.

But then this is where I reiterate that I’m not an expert. This is a detail I’d want to verify with at least a few actual cryptanalysts. Until then, it might be better to err on the side of caution.

[DrQuincy]

Thanks. Yes, I know what you’re saying. I know it’s only anecdotal but ircmaxell works for Google and seems to be extremely well-respected in this area on stackoverflow so I think his opinion is valuable.

I’ve just read about openssl as an alternative and it is a lot faster. Are there many differences, other than speed, between mcrypt and openssl? I see that mcrypt is older and seems to be better documented. It also seems that openssl derives the IV from the salt…is this true and, if so, any less secure?

I’m wondering if I should port over to openssl now as speed is quite important. I’m going way overboard for my client in using 256-bit AES but i want to do so as it’s the only way you learn.

By the way, I read that if you use a block mode that doesn’t require padding, like CFB, then it doesn’t meet AES.

[DrQuincy]

By the way, I read that if you use a block mode that doesn’t require padding, like CFB, then it doesn’t meet AES.

I misread this. It’s if you don’t pad that it doesn’t meet AES. So although block modes like CFB don’t require padding you should pad anyway.

I’m getting to the point of running benchmarks for my client and have two further questions:

1. There are groups of encrypted modules that are to share the same encryption key but have different salts and IVs. Are there any security implications here? I assume not other than brute-forcing can be done quicker as the data is broken up into smaller pieces — but this isn’t an issue if the password strength is good. Note: it would make the system unusable if you needed a different password for each module as sometimes a cfew hundreds modules may be encrypted/decrypted in one go.

2. When performing a lot of encryption/decryptions, 5,000 PBKDF2 interactions are quite slow (yes, I know, that’s the point). If you force a higher password strength (let’s say 12 characters with at least two numbers and two uppercase) does that mean you can afford to have lower interations? I.e. that there is a correlation between hash speed and password strength.