20,313 reputation
12786
bio website
location Paris, France
age
visits member for 3 years, 2 months
seen 46 mins ago

I'm an engineer with experience in applied cryptography, in particular in Smart Card systems.


Jan
18
comment Implementation of modular arithmetic?
Suggestion: "the highest non-zero $b_i$ (for $i<k$) has value $−1$" could be changed to "$b_i=-1$ for the highest $i<k$ for which $b_i\ne0$". Or maybe I could make such minor edits?
Jan
17
comment Which is better ECDHE with TLS 1.0
@CodesInChaos: Any detail or pointer to what substantiates your feeling that RC4 is a worst risk that CBC, given the existence of BEAST? I have no informed opinion about that.
Jan
17
comment Java's SecureRandom & plaintext attack?
@user11424: Now that the challenge is removed and the question tidied, it is acceptable to me. However, are you aware that, as pointed in my first comment (now deleted), your encryption scheme is impractical, for it does not allow decryption with the key, if Java's SecureRandom obeys its own specification, which states that "SecureRandom must produce non-deterministic output" ? Also: it should be stated that the default SecureRandom generator of Java 7 is used, as I assume it is.
Jan
17
comment Java's SecureRandom & plaintext attack?
@user11424: $2^{64}$ operations is no longer considered infeasible. Back in 1998, brute-forcing DES and its $2^{56}$ keys was a matter of 3 days with the EFF DES cracker, and Moore's law has allowed progress by more than $2^8$ since then. $2^{80}$ is still hard, but not inconceivable. $2^{128}$ is safe for a long time.
Jan
16
comment Diffie-Hellman Parameter Check (when g = 2, must p mod 24 == 11?)
@poncho: indeed, RFC 2412, appendix E. There's even the "Note that $2$ is technically not a generator in the number theory sense, because it omits half of the possible residues mod $p$. From a cryptographic viewpoint, this is a virtue.", which confirms your great answer.
Jan
16
comment Diffie-Hellman Parameter Check (when g = 2, must p mod 24 == 11?)
RFC 3526 does not require $g$ to be a generator of the finite field $\operatorname{GF}(p)^*$ of its MODP parameters. For example, the "2048-bit MODP Group" that it defines as $p=2^{2048}-2^{1984}-1+2^{64}⋅(⌊2^{1918}⋅\pi⌋+124476)$, $g=2$ is such that $g^{(p-1)/2}\bmod p=1$. That does not by itself make the parameters insecure, but might be related to why DH_check() fails. Unfortunately, RFC 3526 does not state its criteria for parameters selection; we get that it "follows the criteria established by Richard Schroeppel", without reference, and I fail to find one.
Jan
16
comment Decryption honeypots
@Alexander Torstling: you are right, the decoy can be part of the input, and my wording was ambiguous; I hope that's clearer now. Yes, decoy as used for plausible deniability (e.g. as an option in TrueCrypt) is there in order to make it impossibe to know which plaintext was the intended message, but not to prevent exhaustive key search.
Jan
15
comment Can a salt for a password hash be public?
It would seem that if "to minimize the load on the server, the (bcrypt or scrypt lookalike) hash is calculated at client side", the protocol is vulnerable to passive eavesdropping or disclosure of the hashes, followed by client simulation, unless encryption is used to transfer the hash from client to server; and even with that encryption, that the protocol is vulnerable to MITM, unless there is an initial secret key or public-key certificates.
Jan
15
comment One-Time-Pad with key-reuse: Faster way of decrypting?
As pointed by figlesquidge, $X := A\oplus B$ is very useful; further, you demonstrably get no other clue from the ciphertext if the keystream is random. Also: in ASCII, space is 0x20, and uppercase letters are [0x41-0x5A]. It follows that if the plaintext only uses this, and this is a straight OTP using XOR, then a byte of $X$ has bit 5 (corresponding to 0x20 mask) set only if exactly one of the two plaintext character is a space. When (and only when) both plaintext characters are identical (including but not limited to space), $X$ is 0 (thus has bit 5 clear).
Jan
14
comment Is there a feasible method by which NIST ECC curves over prime fields could be intentionally rigged?
I especially like the contrast with DualEC_DRBG: the key to that backdoor is one in the (asymmetric) cryptographic sense, not a scientific progress as the key to the hypothetical backdoor in P-XXX would be.
Jan
14
comment Are safe primes $p=2^k \pm s$ with $s$ small less recommandable than others as a discrete log modulus?
@catpnosis: Short of SNFS as explained in the accepted answer, I do not know any attack specific to how safe primes are generated. If safe primes are not used and the DLP in $\operatorname{GF}(p)$ matters, Pohlig-Hellman might apply; which is why safe primes are used for (non-ECC) DH and DSA.
Jan
14
comment Where does the $\varphi(n)$ part of RSA come from?
The bit "If we didn't use $\phi(n)$ the mathematics wouldn't work out" is not quite accurate. When $n=p q$ with $p$ and $q$ distinct primes, any positive multiple of $\operatorname{LCM}(p-1,q-1)$ can be used instead of $\phi(n)$ in $e d\equiv 1\bmod{\phi(n)}$.
Jan
14
comment Time complexity to solve Discrete log problem
Thanks for fixing the formula (save for the dots after 1.92). Notice that the little-oh in the exponent makes it impossible to give a big-Oh expression for the complexity. If that $o(1)$ is taken to be $0.01$, the effort is raised by $37\%$ for $1024$-bit $p$, and $52\%$ for $2048$-bit $p$.
Jan
14
comment how do you calculate the private exponent in asymmetric key encryption
Except for the value of $e$, and the use of $\varphi(n)=(p-1)\cdot(q-1)$ rather than $\mathrm{LCM}(p-1, q-1)$, this question is a duplicate of this one which has a fair answer, and others.
Jan
13
comment Is there a feasible method by which NIST ECC curves over prime fields could be intentionally rigged?
My question links to the one that is cited in this answer. And while this answer addresses that other question, it does not directly address my question, which is focused on the techniques than could be used to rig P-192 and friends.
Jan
13
comment Maximal-length LFSR with $n$ bits when the factorization of $2^n-1$ is unavailable?
I get your proof, and it solves my (now gone) interrogation of what $g$ in the generator framework maps to in the LFSR framework. The algorithm allows me to choose a random LFSR that is maximal-length with high probability, and convince someone that I did so. Many thanks! I can't refrain to note that it does not work well for generating a LFSR corresponding to a sparse polynomial, e.g. a trinomial, which has some computational advantage.
Jan
13
comment Maximal-length LFSR with $n$ bits when the factorization of $2^n-1$ is unavailable?
I think that we should choose the feedback polynomial with terms $x^n$ and the constant term set, else I have no proof that even the classical algorithm is correct. We could also choose it with an odd number of terms, since that's a necessary condition for maximal length. Independently: I'd like that others could run the algorithm to check that a LFSR that I propose is maximal-length; if randomizing the non-zero starting state (and perhaps making a few iterations) was demonstrably enough for low odds of letting a non-maximal LFSR creep, that would be perfect; but I'm unsure that holds.
Jan
13
comment Can you show how that RSA does/doesn't provide anonymity?
@Bush: Neither (but now that you have added to the question that the adversary is bound to submit a single message per experiment, mean and maximum are moot). I suggest that you compute a rough approximation of the odds that $(m^e\mod N_A)<(m^e\mod N_B)$ for random $m$, as a function of $N_A$ and $N_B$, the public modulus of Alice and Bob; have a mild illumination to define a strategy for the attacker; and compute the advantage obtained by applying this strategy.
Jan
12
comment Is Truecrypt's multiple/cascading encryption safe?
@catpnosis: I added material in the answer that I hope will answer some of your question.
Jan
11
comment Is Truecrypt's multiple/cascading encryption safe?
@catpnosis: I wrote "compromise of the software" as the first thing to worry about. I maintain that, and every bit in my answer, in light of the recent revelations that you point out. It is rational to be very cautious (not paranoid, by definition of that), but it is nowadays not very rational to use cascading ciphers for bulk encryption.