Reputation
26,464
Next tag badge:
411/400 score
78/80 answers
Badges
2 36 109
Newest
 Revival
Impact
~397k people reached

Jun
5
comment How do we know a cryptographic primitive won't fail suddenly?
" There is only a single cryptographic algorithm that is mathematically proven secure: the one-time pad. " requires an unusual definition of one-time pad to become true: it is easy to define a mathematically proven secure algorithm, as long as it require at least as much key material as the plaintext length. We can use a variety of substitute to XOR. It is even possible to make one where some of the key material is reused (e.g: XOR plaintext with pad used in previous session, then XOR with fresh pad of current session)
Jun
2
comment Advantages/Disadvantages of Bcrypt vs. hash/salt
Yes. In a nutshell, SHA3-512 has not work factor parameter, which is of paramount importance for password storage; and uses little RAM, which in this application is a drawback.
May
29
comment Fast PKI for embedded device
@Ricky Demer: the premise of Quick Verification of RSA Signatures is that quotient estimation is costly (so that handing it with the signature saves significant time). While that's true in some implementations, it does not have to be. In good RSA/Rabin signature verification code, quotient estimation has marginal contribution to execution time, including all precomputation for arbitrary $N$. Efficient quotient estimation in mulmod (or efficient mulmod) would make an interesting separate question.
May
29
comment Fast PKI for embedded device
@Ricky Demer: $\overline\pi$ is just a nothing-up-my-sleeves number for a (relatively well-known) trick to compress the public modulus. DJB is throwing that, and the simple but effective primality test, as additions to his fast signature scheme, which AFAIK has security reducible to factorization independent of these extras. $\;$ I wish the paper had an exposition of the cryptosystem reduced to the main point; perhaps it is best explained in the original disclosure now linked in the answer.
May
28
comment Fast PKI for embedded device
@Ricky Demer: any hint on the tradeoffs in the quoted paper, in particular leak in the proof that ability to break the signature system implies ability to factor $N$ or breaking whatever hash is used?
May
27
comment Why is public key cryptography not widely used in governments?
A QR code is easily copied. Putting a digital signature on a QR code on each ID won't prevent making a copy of a valid ID. It won't even prevent changing the photo on the copy, unless the photo is available from an online database (and if we have this, we hardly need the signature in the QR code).
May
27
comment What is the difference between H(M) and H3(M, s, IDA)?
@Nubila: $H3(M,S,I)=\operatorname{SHA1}(\;M\;\|\;S\;\|\;I\;)$ with all parameters of fixed length will be fine for all but a very powerful adversary: the best known attacks require work of $2^{63\pm9}$ hashes, and so far have not been performed publicly. Same with a single parameter of variable length if you do no not care for the length-extension attack (which breaks security in the ROM, mentioned in version 1 of the question). For output in $\mathbb Z_p$ (as originally asked), see note in answer, and change 512 to 160 for SHA1.
May
27
comment What is the difference between H(M) and H3(M, s, IDA)?
@Nubila: I gave three examples of suitable functions $E$ (sorry I changed notation from $e$ to $E$). If this is for an actual implementation: If any two of $M$, $S$, $I$ are of fixed size, then $H3(M,S,I)=H(\;M\;\|\;S\;\|\;I\;)$ is just fine. Or perhaps $M$ and $S$ are restricted to bytestrings (not bitstrings) and of known maximum length; in which case $E(M)$ can simply be $M$ prefixed with the length of $M$ over a fixed number of bytes suitable for expressing the maximum length.
May
26
comment RSA public key exponent generation confusion
@Robert NACIRI: All hard-coded values of $e$ that I have ever met in practice are prime, I guess for the reasons exposed by Poncho.
May
26
comment Sharing a secret key between many users
For 4096-bit RSA, the overhead for each extra user is about 600 bytes (512 bytes for the cryptogram with the symmetric key, the rest for the user ID and some formatting), not including overhead for conversion to base64 if that's used.
May
26
comment RSA public key exponent generation confusion
1024-bit is also used for certification authorities, and root CA keys, which is becoming obsolete; on the other hand compromise of any Member State key or Tachograph (VU) key would allow breaching the integrity of data recorded in all cards, without possibility of revocation or time limit, longer keys would not have changed this.
May
26
comment RSA public key exponent generation confusion
@Robert NACIRI: I've never met $e=2^{32}+1$ (and that's not a prime, which triggers annoying corner cases in the generation of $p$). Did you mean $e=2^{8}+1$, which indeed is common?
May
26
comment RSA public key exponent generation confusion
An exception to " usually 16 bit value at most " occurs in the European Digital Tachograph, CSM_014, where that is optionally up to 64-bit. Smart Cards that have a certificate (or/and a certification authority certificate) with these extra-long $e$ are annoyingly slower to use than others using $e=2^{16}+1$.
May
26
comment What is the difference between H(M) and H3(M, s, IDA)?
@Nubila: No, " the concatenation of M,S and I " is not a secure hash. $\;$ $H3(M,S,I)$ could be the hash of the concatenation of $M$, $S$, and $I$, with the security issue discussed in the question; and should rather be the hash of the concatenation of $e(M)$, $e(S)$, and $I$.
May
26
comment Is HMAC-MD5 still secure for commitment or other common uses?
@Ricky Demer: agreed, though I fail to see exactly where 192 comes from (unless that's the the 256-bit security level with some safety margin), or why there would be an actual weakness before 513 bits (where the scheme fails abruptly due to the second case of HMAC and our ability to find 1-block collisions on the hash of the K input)
May
25
comment Finding public exponent e
In the brute-force algorithm, step 2, there's $m$ where $c$ is wanted. Also things can be sped up by a factor of two: set $c_1\gets c$; compute $c_2\gets c\cdot c\bmod n$; then repeatdly for odd $i$ increasing from $3$, compute $c_i=c_{i-2}\cdot c_2\bmod n$, until that's $m$, in which case output $i$ which is the desired $e$.
May
20
comment P10 to P8 in S-DES
One should not learn P10 and P8, but understand how they are used. S-DES is not a standard; it's a toy cipher.
May
20
comment Severity of Cooking NIST P Curve Constants
Closely related (slight specialization of?) Is there a feasible method by which NIST ECC curves over prime fields could be intentionally rigged?. Also related to Should we trust the NIST-recommended ECC parameters?
May
20
comment Building a combined encryption scheme from two encryption schemes that's secure if at least on of them is secure
@Ricky Demer: indeed if the first and non-CPA-secure encryption scheme causes an expansion of 1000 bytes for plaintext that starts with the string "fubar", cascaded encryption is insecure, but the answer gives a CPA-secure scheme. Good catch; I will remember considering leaks by size in questions on cascaded encryption.
May
19
comment Building a combined encryption scheme from two encryption schemes that's secure if at least on of them is secure
While this certainly is valid, and matches the hint given in the question before it vanished, I do not see anything wrong with cascaded encryption (using independent keys), which does not depend on a random generator, and has shorter ciphertext.