Reputation
19,455
Top tag
Next privilege 20,000 Rep.
Access 'trusted user' tools
Badges
1 30 79
Newest
 encryption
Impact
~497k people reached

Jan
11
revised Need for salt with IV
added 1223 characters in body
Jan
11
awarded  Nice Answer
Jan
10
comment Need for salt with IV
In any case, IVs don't really have any effect on brute-force password guessing attacks like this; the kind of attacks prevented by proper IV usage are plaintext-recovery (not key-recovery) attacks based on reusing the same key and IV to encrypt multiple message, which can leak information about the plaintexts for those messages.
Jan
10
comment Need for salt with IV
I'm... not sure I've entirely understood the scenario you describe. In any case, with just one user and one password, the only effect salting has is to prevent attackers from precompiling any tables (rainbow or otherwise) to speed up their attack before they've actually seen the hash. While this is useful enough in itself, the main benefits of salting come when there are multiple users, since having a separate salt for each user (or message) prevents an attacker from reusing the same KDF calculation to test the same password against multiple users.
Jan
10
comment Need for salt with IV
You definitely should use both a salt and an IV, unless you have some specific reason not to use both. Generally, the salt should be random, and long enough to be almost surely unique; the requirements for the IV depend on the cipher mode you're using; most modes just require the IV/nonce to be unique, but CBC mode specifically also requires it to be unguessable by an attacker. In any case, a random full-length (i.e. one whole cipher block) IV should generally always be safe. You might also want to consider using SIV mode (RFC 5297), which offers resistance against accidental IV reuse.
Jan
10
revised Need for salt with IV
added 373 characters in body
Jan
10
answered Need for salt with IV
Jan
10
revised openssl wiki description
added 493 characters in body
Jan
10
revised openssl wiki excerpt
added 117 characters in body
Jan
9
comment Why does my SSH private key still work after changing some bytes in the file?
Related question: crypto.stackexchange.com/questions/6593/… (formerly linked from my answer, which I deleted as otherwise redundant to this one).
Jan
9
suggested approved edit on openssl tag wiki
Jan
9
suggested approved edit on openssl tag wiki excerpt
Jan
9
comment How to check the signature without the predetermined function in ECDSA from openssl?
This question (and your followup) might be better suited for Stack Overflow. Crypto.SE is really more for the theoretical side of cryptography (i.e. we'd be happy to explain how ECDSA works, but "how to use OpenSSL" is getting a bit off topic). You may want to see our help center for more information about our scope.
Jan
9
comment Why IV does not have to be secret yet has to be random
This is a nice and well-written answer, but alas, it doesn't seem to answer the actual question asked here, which is (as far as I can tell, the question being somewhat unclear) specifically about CBC encryption and its requirement that IVs be unpredictable. Still, have a +1 anyway. :)
Jan
9
reviewed Reject How much stronger is RC4 if it is keyed with an RSA private key?
Jan
9
comment Do we have anyway of knowing if avoiding self-permutation in RC4 makes it any stronger?
... However, the RC4 internal state also includes the $i$ and $j$ indices, which are initialized to fixed values; thus, the full RC4 state space has $256^2 \cdot 256!$ states, of which only $256!$ (those with $i=j=0$) are possible on the first round (and some, like the Finney states, are provably unreachable on any round).
Jan
9
comment Do we have anyway of knowing if avoiding self-permutation in RC4 makes it any stronger?
@IamNick: All the 256! permutations can, indeed, be reached; to show this, first note that a Fisher-Yates shuffle can produce any permutation, and then that any execution of the Fisher-Yates shuffle on {0, ..., 255} can be simulated by RC4 key setup with a suitably chosen key. In fact, this directly yields an algorithm for reconstructing the key based on the final permutation, which is exactly what I've presented above. [...]
Jan
9
comment Why can’t the public key exponent in RSA be negative?
Good point, @Meysam. I've edited my answer to correct that.
Jan
9
revised Why can’t the public key exponent in RSA be negative?
added 465 characters in body
Jan
9
answered Why can’t the public key exponent in RSA be negative?