Reputation
11,701
Next tag badge:
97/100 score
18/20 answers
Badges
1 25 57
Newest
 Informed
Impact
~189k people reached

May
26
comment How to calculate RSA CRT parameters from public key and private exponent
The $\lambda$ in that calculation, isn't necessarily the usual $\lambda(n)$, right? Only a multiple of it.
May
25
comment Why don't we have hardware generate NON-pseudo, but REAL random numbers from meta-stable flip-flops?
1) The exponential function works pretty well. 128 bits should hold for several more decades and the idea of brute-forcing 256 bits on a conventional computer, ever, is ridiculous. Even the effect of quantum computers isn't that big, they just require you to double the key size. We're at the point where brute-force can easily be defeated and we only need be afraid of cryptanalytic advances (or new physics beyond QM). 2) Of course you still need true random numbers to generate the seed. Having a hardware generator is certainly convenient for that. But that's the only thing I'd use it for.
May
25
comment Using ECB as encryption mode, but encrypted messages are unique
Don't use PKCS#1v1.5 padding, use OAEP.
May
25
comment Why don't we have hardware generate NON-pseudo, but REAL random numbers from meta-stable flip-flops?
1) Current Intel CPUs have a RDRAND instruction and Broadwell adds an RDSEED instruction. 2) Brute force is powerless against the might of the exponential function. If you want to break crypto, you need better cryptoanalysis, not just a faster computer.
May
24
comment Are pseudorandom permutation really permutation in mathematical sense?
It's a permutation, but of the $2^{64}$ possible 64 bit blocks, not of the 64 bits within a single block. If a blockcipher were no permutation, you couldn't decrypt a block.
May
23
comment Curve41417 example
Your example is mod $10^8$. So how is it supposed to relate to Curve41417?
May
23
comment Huffman encoding of hashes
If order doesn't matter, you can sort them and then compress the first few bytes, which rarely change between hashes.
May
21
comment one-way deterministic hash for low entropy input?
Your construction offers no advantage over computing HMAC(key, id) on a trusted device, relying on its rate limiting features and on key being unextractable.
May
19
comment How can a block cipher in counter mode be a reasonable PRNG when it's a PRP?
I wouldn't say that the original version was incorrect, it just didn't mention an important limitation.
May
19
comment How can a block cipher in counter mode be a reasonable PRNG when it's a PRP?
If you like that nitpicky stuff, you might enjoy reading about the "foundations of hashing" problem and why random oracles can't be fully realized using random oracles. Rogaway - Formalizing Human Ignorance, Canetti, Goldreich, Halevi - Random Oracle Methodology, Revisited, Bernstein, Lange - Non-uniform cracks in the concrete, etc.
May
19
comment How can a block cipher in counter mode be a reasonable PRNG when it's a PRP?
@Anon2000 Cryptographers almost always deal with indistinguishability, so the distinction between "real" and "indistinguishable from real" is only made in formal contexts, such as security proofs. For example we don't assume that AES is a PRP, we merely assume it's indistinguishable from one. Cryptography is all about reducing the probability of undesirable outcomes so much that they don't matter in practice.
May
19
comment How can a block cipher in counter mode be a reasonable PRNG when it's a PRP?
@Anon2000 The size of the values is irrelevant, as you already noted, you could concatenate 2 64 bit values to obtain a full block. What matters how much data you output. The security claim for CTR mode is something like "The output is indistinguishable from random data as long as you observe significantly less than $2^{n/2}$ blocks and you don't have enough computational power to bruteforce the key". If you really care, you can quantify that as the probability of distinguishing the random data from the output given the total size of the outputs and the available computational power.
May
19
comment Exist this chat protocol?
The protocol looks silly. The server can passively sniff the traffic between A and B. With a proper protocol the server would have to impersonate A or B, which risks detection if A and B compare their public keys (or a SAS) out of band.
May
19
comment On composition of encryption schemes
Related question: Building a combined encryption scheme from two encryption schemes that's secure if at least on of them is secure (same OP)
May
19
comment Building a combined encryption scheme from two encryption schemes that's secure if at least on of them is secure
Related question: On composition of encryption schemes (same OP)
May
19
comment Building a combined encryption scheme from two encryption schemes that's secure if at least on of them is secure
Gen is clearly the key generation algorithm. Mathematically encryption is often modeled as a tuple of three algorithms, key generation, encryption and decryption. The combined scheme will invoke the two individual key generation algorithms in its key generation algorithm, using the tuple/concatenation of the two individual keys as its key.
May
19
comment Building a combined encryption scheme from two encryption schemes that's secure if at least on of them is secure
@MaartenBodewes I don't see a reason to delete the question. It's not a great question, but it can be answered and might be interesting to some future reader.
May
18
comment Does Ed25519 support cryptographic threshold signatures?
Ed25519 includes $R$ in the message hash. Does that cause problems for the threshold scheme?
May
11
comment ECC vs RSA: how to compare key sizes?
1) The number can't be right. 2048 bits RSA roughly corresponds to a 112 bit symmetric key or a 224 bit ECC key. 2) You wrote a + in the RSA formula where it should be a *. 3) The RSA formula is asymptotic, but you need concrete cost for the comparison.
May
9
comment RSA: How to calculate the private exponent?
You could factor $n$. 33=3*11