19,353 reputation
12676
bio website
location Paris, France
age
visits member for 2 years, 11 months
seen 44 mins ago

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


Mar
21
revised Even passwords are vulnerable to hash collision attacks?
Take comments in account
Mar
20
revised Even passwords are vulnerable to hash collision attacks?
Better justification of the claim "passwords are not vulnerable to hash collision attacks"
Mar
20
revised Even passwords are vulnerable to hash collision attacks?
Tone down "passwords are not vulnerable to hashcollision attacks"
Mar
20
revised Even passwords are vulnerable to hash collision attacks?
final polish
Mar
20
comment Sensible usecase for restricting special characters in passwords?
The traditional reason to prevent special characters in passwords is that sometime the password might need to be entered on a device/context (e.g. physical terminal, bootloader) different from the one where the password is defined on (e.g. some full-blown GUI), and special characters might be difficult or impossible to key in the former environment. Users of AZERTY keyboards often learn the hard way it is safer to choose passwords that key-in identically on a QWERTY keyboard. ^ is especially problematic, for it is a dead key on only some keyboards. This really belongs to security.se
Mar
20
revised Even passwords are vulnerable to hash collision attacks?
typo
Mar
20
answered Even passwords are vulnerable to hash collision attacks?
Mar
19
comment Google is using RC4, but isn't RC4 considered unsafe?
@David Schwartz: things changed.
Mar
19
comment Google is using RC4, but isn't RC4 considered unsafe?
Indeed, there's new stuff; see this and this. The attack seems to recover part of a message repeated in multiple TLS sessions (for some bytes, it starts working at $2^{24}$ repeats). Attacks only get better; they never get worse.
Mar
18
comment What are the constraints for an IV using AES in CBC mode?
More precisely, the IV for GCM shall be such that it (and its increments that will be used) is different from any other IV or increment thereof previously used with the same key. See appendix A in SP-800-38D. session_number|session_sequence|zeroes is usable as IV if the number of zeroes is more than the base-2 log of the number of blocks per messages.
Mar
18
revised BCrypt vs Key Stretching MD5
Expand justification, reference to PBKF2
Mar
17
comment Low Public Exponent Attack for RSA
The lesson from this attack is that RSA encryption MUST pad the message to be enciphered with randomness, distinct for each destination, as in PKCS#1 RSAES; a secondary lesson is that bad uses of RSA tend to get worse with low exponent; it should not be that RSA with low exponent is always weak.
Mar
16
answered What are the constraints for an IV using AES in CBC mode?
Mar
15
revised BCrypt vs Key Stretching MD5
Clarify
Mar
15
answered BCrypt vs Key Stretching MD5
Mar
15
awarded  Nice Answer
Mar
15
comment How to perform Multiplicative Inverse Modulo in IDEA
Straighten notations. CF80 in hexadecimal is 53120 in decimal, but not 3080 by any stretch of imagination; that is -3080 modulo 65536, or -3081 modulo 65537; also, 3080 converted to hexadecimal is 0C08, not 3080. In the context you want unsigned numbers, and displaying them as such (in decimal or hexadecimal). Most importantly, the multiplicative inverse of $x$ is $y$ such that $x⋅y=1$ in the multiplicative group $\pmod{65537}$ (with 65536 mapped to the 16-bit value 0x0000), and you make absolutely no step towards computing that $y$ when $x$ is 53120 or hexadecimal CF80, your goal.
Mar
15
comment How to perform Multiplicative Inverse Modulo in IDEA
That solution uses that for $p$ prime and $x\not=0\bmod p$, we can compute $x^{-1}\bmod p$ as $x^{p-2}\bmod p$; and builds the 65535th power by a (non-obvious) addition chain. Of course, operator $⋅$ is multiplication $\pmod{65537}$ (with $65536$ mapped to the 16-bit value 0x0000), as used elsewhere in IDEA. This is useful in the context of preparing a key for decryption in IDEA, for it gives the right result without any test, thus no timing dependency beyond that of $⋅$, which would leak information about the key.
Mar
13
comment Encrypting many small messages (log-lines)
Perhaps, indicate what was the bit size of the modulus, and the value of the public exponent $e$, and (concisely) what sort of environment that was (e.g. crypto library built in JRE 6); this will make the numbers more relevant. Perhaps try RSA with e=3 instead of 65537 and I guess you'll get much better speed.
Mar
13
comment Security of tokenization of plain text conversations - cryptanalysis
If the observation that "new" is encoded identically in two different messages applies to the real system (rather than a marketing video only), this is enough to tell the real system is pure snake oil. Further, a company that let its marketing video have this kind of clear defect should be suspect.