Ilmari Karonen
Reputation
16,021
76/100 score
 Mar 3 comment Affine transformation in finite field SubBytes $0 1 0 1 0 0 1 1 \odot 1 0 0 0 1 1 1 1 = 0 0 0 0 0 0 1 1$; $\ 0 \oplus 0 \oplus 0 \oplus 0 \oplus 0 \oplus 0 \oplus 1 \oplus 1 = 0$ (where $\odot$ denotes bitwise AND, and $\oplus$ denotes XOR). Does that make it any clearer? 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 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.