Reputation
14,175
Next tag badge:
109/100 score
19/20 answers
Badges
1 14 61
Newest
 Curious
Impact
~290k people reached

Mar
1
comment Why would cryptography fall apart if there were a finite number of primes?
Given that it's quite easy to prove that the number of primes isn't finite, this is sort of like asking "why would cryptography fall apart if 1 + 1 wasn't 2?"
Mar
1
comment How obvious is it to decrypt numerics encrypted with a reused one time pad?
Yes, that's exactly what format-preserving encryption does. Basically, an FPE scheme for, say, dates within a year, is a keyed invertible pseudorandom permutation of the set {1, 2, ..., 365} (plus 366 for leap years; of course, in practice, you'd also want to use the year as a "tweak" for the scheme, so it won't be the same permutation each year). Every time you feed in the same unencrypted date, the same encrypted date will come out; it will just tend to flatten out any long-term monthly / weekly trends, since the dates will be shuffled around (pseudo)randomly.
Feb
17
comment Given infinite unencrypted and encrypted texts, can I find the algorithm?
If the encryption is a one-time-pad, no, you can't. For most practical cryptosystems, assuming you also have infinite computational power, yes (or at least you can find something that is as good as the key for any practical purpose).
Feb
17
comment Crypto++: How to re-generate pseurandom integers in Crypto++
@Maarten: True enough. FWIW, HKDF can generate an endless stream of data, at least if you implement it yourself; perhaps more usefully, even if you're using a pre-built implementation that wants the output length up front, it can still generate arbitrarily many quasi-independent output strings, if you feed it distinct info strings for each output. So, to generate a key X with a rejection sampling scheme, you could ask for keyX/1, then keyX/2, etc., until you get an acceptable output.
Feb
15
comment How to accurately calculate Unicity Distance for English?
Yes, the unicity distance is only as correct as the estimate of plaintext entropy it's based on. It's not possible to assign a single objective unicity distance to a cipher, since it depends on the plaintext entropy, which in turn depends on the distribution of plaintexts being encrypted (and, for practical cryptanalysis, on how much we know about this distribution, and on how good we are at recognizing valid plaintexts). If you use DES to encrypt a stream of random bits (r=8), its unicity distance is infinite; if you use it to encrypt a known constant string (r=0), it's 7 bytes (= 56 bits).
Feb
15
comment How to accurately calculate Unicity Distance for English?
Now, to relate this to decryption, let's say you had the wrong key, and decrypted the first two letters as CH instead of PU; would this be enough for you to tell that the key is wrong? Now, what if, instead, you had already decrypted PUZZ, and got YR as the next two letters? Would you consider that as sufficient evidence to reject the key (or at least assign it a very low probability), even though the first four letters looked plausible enough?
Feb
15
comment How to accurately calculate Unicity Distance for English?
(Quick example: I'm thinking of an English word; which letter does it start with? I bet you didn't guess that it's P! Now, the word continues with U, Z, Z; can you guess the next letter now?)
Feb
15
comment How to accurately calculate Unicity Distance for English?
Honestly, I'm not sure what you're trying to say above. For your first comment, are you really saying that, even after decoding 12 bytes, you still get multiple plaintexts that look like plausible English text? As for your second comment, the point I was trying to make is that it's a lot harder to predict the first letter of a string than one of the later ones; the estimate of $r=1.5$ bits of entropy is only reasonable for those later letters.
Feb
15
comment Crypto++: How to re-generate pseurandom integers in Crypto++
That's why I would suggest not using RandomPool. (Another reason is that, as far as I can tell, the exact algorithm used by RandomPool is not documented, so there's no guarantee that the output won't change between different Crypto++ versions.) Instead, just implement your own pseudorandom bitstream generator (like one of the NIST DRBG algorithms) using the primitives provided by Crypto++ (e.g. SymmetricCipher or HMAC).
Feb
14
comment Counter Mode (CTR) and mult-CPA
Would you mind giving the definition of "mult-CPA" security you're using? I tried Googling for it, but the only use of that term I found was in these German lecture notes, which also say that it's equivalent to ordinary CPA security.
Feb
14
comment Which characters to take into account when calculating unicity distance?
The math is correct, as far as it goes, but the unicity distance is measured in characters, not in bits (at least if $D$ is measured in bits / character; if you measured $D$ in, say, bits / cipher block, then $U$ would be in cipher blocks). So the correct answer should be $U\approx 23.27$ characters (except that this assumes 7-bit bytes, even though pretty much every digital cipher ever works on 8-bit bytes, so $D$ should be around $6.5$, not $5.5$, giving $U\approx19.69$ characters -- pretty close to @poncho's 20 characters).
Feb
9
comment Is there any advantage on encrypting the CMAC together with the message?
If you have any influence on this scheme, I would strongly suggest replacing it with AES-SIV, which is based on the same primitives (AES, CTR mode and CMAC), but is stronger (128-bit tag), less vulnerable to misuse (can be used even without an nonce), may have less overhead (assuming your scheme transmits an IV/nonce for CTR mode) and has an actual security proof.
Feb
9
comment Noisiest RF band for random number generation
+1 Besides, using RF noise for random numbers is wide open to active attacks: an attacker can just transmit on the frequency your RNG is tuned to.
Feb
8
comment RSA with composite numbers
Related: crypto.stackexchange.com/questions/5170/…
Feb
8
comment Simple multiplication as an encryption method
See the part below the horizontal line.
Feb
3
comment CPA security of a stateless and deterministic encryption system
Essentially the same argument also works for symmetric ciphers, since the definition of IND-CPA security assumes that the attacker has access to an encryption oracle.
Jan
14
comment Specification of the Megamos crypto algorithm
Just for posterity, let me note that the protocol description that you quote above, via the cybergibbons website, appears to be originally quoted (without attribution, alas) from my answer to this question. (The cybergibbons version also has what appears to be a minor editing mistake in the second-to-last step, where it reads ${\rm T \to C}: r,G$ instead of ${\rm T \to C}: G'$, but you seem to have fixed that.)
Jan
6
comment Encryption for a short packet size
@BaruchEven: Yes, counter mode is safe even with predictable IVs, as long as they're never repeated. Generally, only CBC mode (and certain variants of CFB) requires unpredictable IVs.
Jan
5
comment Why is the private key generated first in public key crypto?
@yyyyyyy: In fact, many RSA implementations do store $p$ and $q$ as part of the private key, since doing so allows using the Chinese remainder theorem to speed up the algorithm.
Jan
3
comment Why are there no MACs inspired by block cipher modes other than CBC and CFB?
Please clarify your question, especially the statement quoted by Ricky. None of the traditional cipher modes (ECB, CBC, CFB, OFB and CTR) include a MAC, nor can they be (directly) used as one. There are MAC constructions that do bear some resemblance to these modes, such as CBC-MAC and its modern replacement CMAC, but those are separate constructions (although CBC and CBC-MAC do work very similarly). (Also, MAC usually stands for message authentication code; if you really mean mutual, please clarify that too.)