Reputation
Top tag
Next privilege 20,000 Rep.
Access 'trusted user' tools
Badges
1 30 79
Newest
 encryption
Impact
~501k people reached

Mar
3
revised How to compare between two cryptographic algorithms in terms of security?
copyedit, incorporate additional info from comments
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.
Mar
1
answered How obvious is it to decrypt numerics encrypted with a reused one time pad?
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
revised How to accurately calculate Unicity Distance for English?
use mathjax, copyedits, tags
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
answered Crypto++: How to re-generate pseurandom integers in Crypto++
Feb
14
revised Counter Mode (CTR) and mult-CPA
copyedit, better tags
Feb
14
answered Counter Mode (CTR) and mult-CPA
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
revised How to accurately calculate Unicity Distance for English?
fix broken formatting
Feb
14
answered How to accurately calculate Unicity Distance for English?
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).