16,808 reputation
12266
bio website
location Paris, France
age
visits member for 2 years, 8 months
seen 9 hours ago

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


Jun
5
comment In ECDSA, how many field operations are used for signature verification?
@CodesInChaos: so that's 1500 squarings and 1500 multiplications in the base field. Makes sense. Thanks.
Jun
5
comment Secure use-cases of block cipher with 64-bit block size
@user7060: all common operating modes except ECB are safe (from the standpoint of insuring confidentiality of the message) including with small-block cipher and low-entropy plaintext, subject to the conditions I state in my answer. Further, CTR and to a degree OFB allow to go over the bound stated for the number of blocks in my second point in some cases, including when a key is only used with a single message.
Jun
5
comment How can I split a message in parts of similar size or smaller?
If the $160$ characters are arbitrary among $256$ values, and the set of type-able characters has $64$ values, then by a counting argument you need one of the $3$ parts to have $\lceil{160\over 3}\cdot{{\log_2(256)}\over{\log_2(64)}}\rceil=72$ characters, which is hardly type-able. Without arbitrary, you could compress the message beforehand.
Jun
5
comment Secure use-cases of block cipher with 64-bit block size
@user7060: When you encipher a generated key with a master key, an adversary will typically be able to check a guess of the master key, by deciphering the encrypted generated key then testing the resulting candidate generated key in whatever context generated keys are used. Hence you need a wide enough master key to resist brute force. This rules out DES, but not many other 64-bit ciphers (see first point in my answer). To some degree, ECB is undesirable if the generated key is wider than 64-bit, as it often should be.
Jun
5
comment Secure use-cases of block cipher with 64-bit block size
@user7060: 64-bit block ciphers are deprecated for new applications, but still very much in use in some fields, including mine (Smart Cards). French recommendations recommend 128-bit block ciphers, but allow 64-bit block ciphers (for introduction) till 2020, provided they are used within rules.
Jun
4
comment Secure use-cases of block cipher with 64-bit block size
Indeed the question changed; yet the original was "about 64-bit block ciphers", and the reference to Blowfish makes it clear enough that 64-bit is intended as the block size.
Jun
4
comment HMAC and assumptions on the cryptographic hash
For modern criteria for HMAC security, I recommend New Proofs for NMAC and HMAC: Security without Collision-Resistance, although it is hard reading and some of it goes over my head.
Jun
4
comment Secure use-cases of block cipher with 64-bit block size
I read the question as about 64-bit block width, not 64-bit key width. This answer seems about the later, and I thus disagree.
Jun
4
comment With HMAC, can an attacker recover the key, given many known plaintext/tag pairs?
My first reason for downvote was as stated by D.W. in the comment above: a minimum of research should have been done, and would have revealed that the definition of security of HMAC, and its unbroken status, directly implies that the answer to the question as in its body is: no, assuming $k$ is wide enough.
Jun
4
comment ECC Point Multiplication of Product
Where do you get $n$ from? What do you get when you compute $nG$?
Jun
3
comment Can i modify data “protected” by a CRC16?
Many CRCs in actual use do not have the property that $\crc(x⊕y)=\crc(x)⊕\crc(y)$. Instead that have the weaker property that for any three messages $x$, $y$, $z$ of equal length, $\crc(x⊕y⊕z)=\crc(x)⊕\crc(y)⊕\crc(z)$. Look at section 2.2.7.4 of X.25, and consider the effect of the prescribed initialization value, and final complementation. Still the attack remains possible.
Jun
3
comment With HMAC, can an attacker recover the key, given many known plaintext/tag pairs?
Another reason for my downvote is that the title does not match the body of the question. I fully agree to this answer, and that it answers the question as worded in its body. But I would not be so sure the question in the title can be answered with no, or at all. Revealing one $m$ and even the low-order bit of $HMAC(k,m)$ "leak information" on $k$ in some sense, for about half the $k$ can be eliminated.
Jun
1
comment Why crypto hash functions must be collision resistant and how to find resistant?
Another note: signature schemes do not "encrypt the digest"; they apply some secret cryptographic function, which is not encryption, to the digest. In RSA signature with appendix (RSASSA), the function happens to be the composition of a public "padding" function, and the function $x\mapsto x^d\bmod N$, known as textbook RSA decryption (not encryption).
May
31
comment What do recent announcements about solving the DLP in $GF(2^{6120})$ mean for RSA
@Samuel Neves: thanks for pointing that serious mistake! Fixed.
May
31
comment Why crypto hash functions must be collision resistant and how to find resistant?
The main argument is valid only if "break the function" is defined in term of collision resistance, and then it is a circular argument. There are uses of a hash function where collision-resistance is not a required property; e.g. in HMAC, see this. +1 nevertheless for the distinction between collision-resistant and collision-free.
May
31
comment Why crypto hash functions must be collision resistant and how to find resistant?
The description of digital signature is valid for some signature schemes; and there are other uses of hash algorithms where collisions would be a problem. The argument remains excellent.
May
31
comment Reversing SHA1 (don't know the correct term)
@Smit Johnth: with current block data, here pad(B), yes you can "generate expanded buffer"; but, even knowing the final hash, your intuition that you can "reverse the hash generation to beginning of the block" seems wrong to me, based on the fact that the round function $S_{j+1}=F(S_j,M_j)$ has the structure $F(S,M)=E_M(S)\boxplus S$ where $E$ is a block cipher, and $\boxplus$ is some hybrid between addition and XOR.
May
31
comment Do recent announcements about solving the DLP in $GF(2^{6120})$ apply to schemes proposed for cryptographic use?
Many thanks! I'll try to assimilate that dense answer before accepting it; that'll take a week, at least.
May
30
comment Reversing SHA1 (don't know the correct term)
@Smit Johnth: last time I checked, SHA-1 had an (input) block size of 512 bits, that is 64 bytes, not 20 bytes. Regardless of how pad() pads: no, I do not think that you can do what you ask for.
May
29
comment Do recent announcements about solving the DLP in $GF(2^{6120})$ apply to schemes proposed for cryptographic use?
@Henrick Hellström: For a basic case: what about an anolog of DSA on $GF(2^{4099})$ [NOT $GF(2^{4096})$ as I wrote previously, showing my serious lack of understanding]? Is the technique in the paper directly applicable, or is there some catch, like $6120$ being smooth, rather than prime?