20,355 reputation
12787
bio website
location Paris, France
age
visits member for 3 years, 2 months
seen 4 hours ago

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


Jan
19
comment How to ensure that a “received value” is not altered?
@Pacerier: Since the messages to protect inherently reflect the evolving will of a human, they can't be predetermined then revealed. Looks like you'll need other techniques: central clearing server, hierarchical PKI, or distributed trust based on individual private/public key pairs, to name some of the main families of applicable techniques; some of these might benefit from trusted hardware (Smart Cards).
Jan
18
comment How to ensure that a “received value” is not altered?
@Pacerier: if you can't assume a secret key in your software generating the message that is to be integrity-protected, then a MAC is not a solution, and I have worse news: there is not anything any cryptographic algorithm alone can do for you. You need to turn around the problem: perhaps find a way to keep a key secret (Smart Card ICs, or substitutes like OS-managed security); or modify the meaning of generating the message so that it becomes revealing an inherently verifiable message.
Jan
18
comment How to ensure that a “received value” is not altered?
Can you assume that a key embedded in the software remains secret? If yes, the simplest solution to your problem seems to be a MAC, such HMAC with SHA-256, used to generate verification_value as HMAC(key,0.230957203975), and re-generated from the alleged 0.230957203975for verification purposes.
Jan
18
comment How to ensure that a “received value” is not altered?
In 2, there is the problem that anyone (with your public key) can compute the verification_value accrediting a fake, and even you can not detect that.
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.