Reputation
18,498
Top tag
Next privilege 20,000 Rep.
Access 'trusted user' tools
Badges
1 27 75
Newest
 aes
Impact
~440k people reached

2d
comment Find the minimum Adversary's Advantage
@stathisb: Are you missing the definition of advantage for MAC schemes, or the way to obtain a non-negligible advantage for this particular question (or something else)? If the former, your textbook (or lecture notes) should have it, assuming that it's using the term "advantage" for MACs in the first place; if the latter, see my answer below.
2d
comment Find the minimum Adversary's Advantage
@stathisb: ...where you've now introduced three new undefined symbols ($K$, $M$ and $T$). I can guess what those mean (I bet they're the keyspace, message space and tag space respectively), but such notation isn't really unambiguous or universal enough that you could just assume that everybody will understand it (they way in math you can usually assume e.g. that $\pi \approx 3.14159265$), especially if they learned crypto from a different textbook than yours. But anyway, more important than all this notation is really that you still haven't told us what you've tried and where you're stuck.
2d
comment Find the minimum Adversary's Advantage
@RickyDemer: I suspect it just means that they're representing their MAC scheme as a pair of functions $S$ and $V$, which probably stand for "signer" and "verifier". Wikipedia uses a similar notation. But yeah, the question should really mention that, or at least link to a definition.
2d
comment Security of a parallelizable block cipher mode
Also, this construction looks vaguely similar to OCB mode. Are you familiar with that?
2d
comment Security of a parallelizable block cipher mode
Maybe a silly question, but what's $\boxplus$? I assume $\oplus$ means bitwise XOR, but I don't really know a standard meaning for $\boxplus$.
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 Is there any code implementation of the HMAC-DRBG PRNG?
If user1193112's advice doesn't solve your problem, you might want to ask this on Stack Overflow instead. Note that requests for existing implementations are considered off-topic there too, but if you rephrased your question as "How can I implement HMAC_DRBG from NIST SP 800-90A in C#?" (or C++; please pick one), and provided some indication of what you've tried and where you're stuck, it should be on-topic there.
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. [...]