20,510 reputation
32473
bio website
location
age
visits member for 3 years, 2 months
seen 18 hours ago

Sep
12
comment Break a simple compression function of a cryptographic hash function
Also, you should specify how long unsigned long long is, on your machine model. Is it a 64-bit integer? You should specify what you mean by "sum of the last compressions". Do you mean the sum of all previous results from the compress function? If so, is it addition modulo $2^{64}$ (not, say, xor)?
Sep
12
comment Break a simple compression function of a cryptographic hash function
In what context did you run into this? Is it a homework, or did you find it in some real system (if so, which?)? If it is a homework, what have you tried so far? We don't do your homework for you; we expect you to tell us what you've tried and where you got stuck. I suggest you edit the question to make these points more explicit.
Sep
12
comment Can the AES encryption and decryption algorithms be described as a polynomial for a specific key?
@pg1989, right, that's why I said it does not seem to help cryptanalyze AES. :-)
Sep
11
comment Hide a weakness in ECC by choosing the prime or one of the curve coefficients
Thanks, @poncho! Revised accordingly. I appreciate it.
Sep
9
comment Should we trust the NIST-recommended ECC parameters?
Contrary to what you wrote, choosing random seeds is not just as good, because it provides no way to demonstrate that they didn't cook the parameters. Suppose that, say, 1/1000000000 of curves are vulnerable to some obscure attack that the NSA has discovered but that is not known to the public world. Then choosing an arbitrary seed would let them select a curve that is secretly vulnerable to their secret attack. (For what it's worth, the person who chose the ECC parameters for NIST was apparently... wait for it... a NSA employee.)
Sep
9
comment Should we trust the NIST-recommended ECC parameters?
I'm not looking to fault anyone or to avoid ECC. I just want to know whether there are justifiable grounds for trusting the NIST ECC parameters. I don't think that's unreasonable or harsh. (I think the world of NIST; they are truly a boon to society, and I have great trust and respect for the NIST employees that I've gotten to know. But that doesn't make the question go away; there is still the question of whether there are justifiable technical grounds for confidence in these parameters.)
Sep
8
comment Automated security protocol verification tool for eCK model
@Alex, odds are it's a problem on your end. You shouldn't give up on it so quickly. If you're going to expect a tool for this sort of thing, you're going to have to be resourceful, to be prepared to do some non-trivial hacking, and to deal with research-quality code, not polished commercial offerings. If that sounds unappetizing, then I recommend you give up on your idea of finding tools for protocol verification, and hire a consultant who will do the cryptographic analysis for you.
Sep
7
comment Can S/MIME be still considered secure?
In the future, it is often better to migrate questions, rather than cross-posting or duplicating them. (It's better still to ask at the right place from the start, if you know what the right place is!) No biggie; just wanted to let you know for the future.
Sep
7
comment Can stream ciphers (usually) be “run backwards”?
Poncho is right. Poncho never claimed that an arbitrary permutation is safe. What is true is that a random permutation is safer than a random function: this is because the expected cycle length for a random permutation on $n$ bits is $(2^n+1)/2$, whereas the expected cycle length for a random function on $n$ bits is $\sqrt{2^n}$, a huge difference. To the extent that the next-state function is intended to be indistinguishable from a random permutation, it is safer against short-cycle problems than a next-state function that is intended to look like a random function.
Sep
6
comment Camellia or AES - which should I use?
... And yes, I know how I would answer, and I know the answer (on a technical level) is likely to be painfully obvious to anyone on this site... but I'm hoping someone will write an answer that serves as a general reference that I can point others to.
Sep
6
comment Who uses Dual_EC_DRBG?
@MichaelKjörling, I don't think the standard reasons for discouraging link-only answers apply here. It is part of NIST's job to maintain the list of algorithms that they've validated, so I don't think they're going to just stop publishing the list. Moreover, they are the authoritative source of this information, and the information changes over time, so copying the information there into this answer would be a bad idea (this answer would get out of date). Bottom line: I think pointing to the authoritative source for this information is useful and appropriate, in this case.
Sep
6
comment Known-plaintext attack on Blowfish in ECB mode
@AntonSamsonov, I've edited my answer to explain in greater detail. For more detail, please read about the Hellman time-space tradeoff and rainbow tables to make sure you understand them before diving into this any further.
Sep
6
comment Known-plaintext attack on Blowfish in ECB mode
@AntonSamsonov, each step is one trial decryption of one block of data (e.g., the key setup + the decryption operation of Blowfish). The way that "rainbow tables" work is by inverting some one-way function $f(x)$. If $c$ is a Blowfish encryption of a known plaintext $p$, we can define $f(k) = E_k(p)$ and then use rainbow tables to find the $k$ such that $f(k)=c$.
Sep
4
comment Known-plaintext attack on Blowfish in ECB mode
Actually, @PaŭloEbermann, ECB mode can be much worse than other modes for key-recover attacks (because it makes it easier to do time-space tradeoffs, if you have a full block of known plaintext). However that doesn't seem to apply here.
Sep
4
comment Known-plaintext attack on Blowfish in ECB mode
What protection scheme are you referring to? (Is there some reason to keep it secret?)
Sep
4
comment Known-plaintext attack on Blowfish in ECB mode
Where did you encounter this? What application uses this scheme?
Sep
4
comment What is the relation between hash chaining and chosen prefix attack
@user129789, no it doesn't. That's a totally different sort of chaining than the one in the lecture notes you posted in your earlier comment. Like I said in my comment on the question, first you need to be clear about what you mean by "hash chaining", and edit the question to make that clear. You seem unclear on what you even mean by that phrase -- so how do you expect us to answer your question, if you're not even clear on what you're asking?
Sep
3
comment One-way function and $EXP$
"even if $P=NP$ this not immediately correct that we can easily invert one way functions" - Yes it is. If $P=NP$, all one-way functions can be inverted in polynomial time. This is a simple theorem. (Remember, a one-way function must be computable in the forward direction in polynomial time. This means if you have a guess at the inverse, you can check whether your guess is correct in polynomial time. That in turn means that finding the inverse is a problem in $NP$: it's a problem whose solution can be verified in polytime, which is basically the definition of $NP$.)
Sep
3
comment Why the symmetric key layer in PGP?
See crypto.stackexchange.com/q/14/351 and crypto.stackexchange.com/q/586/351 and crypto.stackexchange.com/q/5782/351, which already contain answers to your question.
Sep
2
comment What is the relation between hash chaining and chosen prefix attack
@user129789, it doesn't prevent collisions; it is just a strategy for dealing with collisions when building a hash table. And, the context of those lecture notes has nothing to do with cryptography, and thus nothing to do with this site.