23,723 reputation
23199
bio website
location Paris, France
age
visits member for 3 years, 7 months
seen 16 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
revised Java's SecureRandom & plaintext attack?
More carefull wording of what the analysys I link to is
Jan
17
answered Java's SecureRandom & plaintext attack?
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
17
revised Ephemeral Diffie-Hellman generator selection
in addition TO
Jan
17
revised Ephemeral Diffie-Hellman generator selection
Cover the criteria of IKE; rework.
Jan
17
revised Ephemeral Diffie-Hellman generator selection
Cover the criteria of IKE; rework.
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
revised Decryption honeypots
Further expand
Jan
16
revised Decryption honeypots
Expand
Jan
16
revised Decryption honeypots
Clarify that decoy is indeed used
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
16
revised Decryption honeypots
Update to resolve an ambiguity of what a "that" refered to, per comment
Jan
16
revised Ephemeral Diffie-Hellman generator selection
Add restriction "as long as there is a single $g$ used for a given instance of other parameter(s)", and references to NIST standards
Jan
15
revised Ephemeral Diffie-Hellman generator selection
Add GNFS and reference
Jan
15
answered Ephemeral Diffie-Hellman generator selection
Jan
15
revised Decryption honeypots
added 58 characters in body