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

Feb
1
comment SHA1 collisions and the impact for ECDSA signatures
If the attacker only has control over $m'$, then they need a (second) preimage attack to forge a signature. But there are practical scenarios where both $m$ and $m'$ may be controlled by the attacker, in which case a collision attack suffices. For example, the MD5 collision attack was used to forge SSL certificates by getting an established CA to sign an innocent-looking certificate, and then replacing it with another certificate with the same MD5 hash, but far higher privileges.
Feb
1
comment Can an AES-256 key be generated for a large number of cribs?
We seem to be getting questions like this one with some regularity. Alas, the answer is always the same: if the virus writer didn't screw up somehow (and didn't get arrested and forced to surrender their private keys), you can't break the encryption.
Jan
25
comment Proving that a node is the only child
Are we allowed to update the hashes of existing nodes when new nodes are added? (I assume yes, since the problem is obviously unsolvable otherwise, but it would be good to state this explicitly in your question.) And are there any constraints on which hashes we may update (e.g. can we update the hashes of the added node's siblings, or only the hash of its parent, or...)?
Jan
23
comment Complexity using RSA
Not off the top of my head, because I don't have the "standard exponentiation algorithm" memorized. Also, now that I think about it, are we allowed to choose $e$ freely? Using $e=3$ should make the exercise simpler and also allow a higher $m$ than using a random $e<n$. (Also, the constant factor 100 in the assumed cost of multiplication seems pretty high, at least for multiplication by a small constant.)
Jan
20
comment Complexity using RSA
For bonus points, mention that you would never use RSA like this in practice, because it's both inefficient and insecure.
Jan
18
comment Compromise between HMAC and Digital Signature, by encrypting and sending secret key?
@user29944: To be precise, I meant to say that the time needed to hash the message is strictly less than the time to HMAC (or sign) it, simply because hashing the message is one step in both HMAC and in signing. Typically, the full signing process will be somewhat slower than HMAC; but the difference is by a constant amount (depending only on the signature and hash algorithms, and on the signature key length), and thus becomes relatively insignificant for sufficiently long messages.
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
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
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
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
comment Why can’t the public key exponent in RSA be negative?
While not precisely a duplicate, at least my answer to this related question also answers yours.
Jan
9
comment Do we have anyway of knowing if avoiding self-permutation in RC4 makes it any stronger?
Technically, since RC4 key length is capped at 256 bytes (and the key is repeated if it's shorter than that), just concatenating $k_{ip}$ and $k_u$ won't work; you'd have to actually run the key setup twice, first with $k_{ip}$ and then with $k_u$. Still, for any initial permutation $p_1$ and any target permutation $p_2$, there is an RC4 key (possibly several, in fact, but at least one is easy to find) that transforms $p_1$ into $p_2$. In that sense, every key in the OP's modified RC4 is provably equivalent to some key in normal RC4.
Jan
7
comment Rule 30 Cellular Automaton for Cryptography
This paper seems to say "no, it's not secure", but I haven't read it fully yet.
Jan
7
comment Why IV does not have to be secret yet has to be random
You may also find this question useful.
Jan
7
comment Permutation of keys that guarantees different hashes
@fgrieu: I suspect the OP actually wants $$\exists H,m\ \forall x,y: (x \ne y \land H(x) = H(y)) \implies H(m(x)) \ne H(m(y)),$$ rather than $$\exists H,x,y\ \forall m: x \ne y \land H(x) = H(y) \land (m \ne {\rm id} \implies H(m(x)) \ne H(m(y))).$$