Reputation
26,574
Next tag badge:
419/400 score
79/80 answers
Badges
2 37 112
Newest
 Benefactor
Impact
~410k people reached

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.
May
18
comment Could this alternative hash based MAC construction be as, or even more secure than an HMAC?
@Anon2000: in crypto perhaps more than elsewhere, the devil is in the details. If you look closely at a typical SHA-1 implementation, the state has the 160-bit chaining variable so far, the length so far (usually 64-bit, could be in bits or bytes), and the message-block-not-hashed-yet (usually up to 511-bit, which length may or may not be tracked separately). If you want a portable implementation enciphering or hashing that, you need to care of all these details, including endianness and order of the various fields. If you consider only the chaining variable, you must be careful about padding.
May
18
comment Could this alternative hash based MAC construction be as, or even more secure than an HMAC?
(continued) if for some reason the length of the message is not known at the beginning of the MAC, there's the more elaborate CMAC; or OMAC2. Do not use straight CBC-MAC with a variable-length message.
May
18
comment Could this alternative hash based MAC construction be as, or even more secure than an HMAC?
If you are concerned with speed of a MAC and have hardware-accelerated AES encryption, you definitely want to consider CBC-MAC with the length of the message at start, and right-padding of the message with zeroes; this is demonstrably secure (when using a key dedicated to MAC), and even standardized as ISO/IEC 9797-1:2011 Padding Method 3. As they put it: "The [first] block consists of the binary representation of the length (in bits) of the unpadded [message], left-padded with as few (possibly none) ‘0’ bits as necessary to obtain a [128-]bit block".
May
18
comment What is the difference between online and offline brute force attacks?
Yes; but that's typically not the meaning of online in cryptography, as understood in online brute-force attack.
May
18
comment Does failure of indistinguishability of encryptions imply lack of CPA-security?
Yes, except for use of OTP as an example. Let's take the semantic step of considering that the OTP can be subjected to the test while still remaining worth of its name, despite the fact that a single key $k$ is drawn at step 1, and it is shorter than the total (or even individual) size of messages at 2 and 4. We have to admit that this OTP is used with the same pad at each use in 2 and 4 (with the pad a repetition of the key for longer messages). This OTP fails the test of indistinguishablity of encryptions under eavesdropping, and is thus not a proper example of the point discussed.
May
18
comment What is the difference between online and offline brute force attacks?
@Jingwei: OK for that description of offline brute force attacks; for online brute force attack, what's important is that the other entitie(s) is/are what is under attack. I'll add a note to clarify.
May
17
comment Is the HMAC construction really neccessary for a fixed length message?
@Anon2000: for your need of a fast MAC, have you considered Siphash?
May
17
comment Is One Time Pad considered Chosen-Plaintext Attack Secure?
@Gordon: Yes, I used cipher where I meant encryption scheme! My mistake! And I'm the one trying to be rigorous, shame on me. That's fixed. $\;$ Now I'm not in a position to object against your definition of OTP, which allows reusing the pad, making it an encryption scheme (that is not secure in any definition of that).
May
17
comment Is One Time Pad considered Chosen-Plaintext Attack Secure?
@Gordon: I (now) see what you mean. If we consider that the OTP allows key reuse then, yes, it is a cipher (perhaps, by a variation of the above definition where the plaintext size is restricted), but not a secure one under even the weakest definition of security (unknown plaintext with known redundancy). On the other hand, two of out three words in the name One TIme Pad are there to emphasize that the pad/key can not be reused, so this twists the definition of OTP.