Reputation
2,673
Top tag
Next privilege 3,000 Rep.
Cast close & reopen votes
Badges
10 26
Newest
 Quorum
Impact
~41k people reached

Apr
17
comment Compare Blockmode CBC (with diffuser) against XTS
@Yura That will depend on how AES is used (XTS for example, usually is built on top of AES). If you use CTR-AES mode twice, the result doesn't become less malleable (flipping a bit in the ciphertext still flips the corresponding bit in the plaintext). If you use CBC-AES mode twice, you can still do the same attack I mentioned in my answer, but the length of the uncontrolled random "garbage" section will double. Finally, using AES in a secure "wideblock" mode would be roughly as fast as either of these solutions, anyway. So might as well do that, instead.
Mar
22
comment What is the benefit of artificially padding messages?
Where did you hear this? In some cases there may be a minor benefit to hiding some information about a message's length, you may be misinterpreting what you've read: If you want to allow messages that aren't a multiple of the block size, then padding is required even for a message that is a multiple of the block size. Otherwise, how can you tell a padded message apart from a plaintext that happens to end in a sequence of bytes that is also valid padding?
Oct
15
comment Values of p and q when e = 3 (RSA)?
Do you need to know how to find large primes, or just how to find large primes with that property?
Sep
29
comment How can a Encrypt-And-MAC scheme be insecure if the encryption is CCA secure?
Is this homework? Some things to consider: What happens if a message is repeated? Can you construct a MAC that is unforgeable under a chosen message attack, but that leaks information about the input?
Jun
21
comment Turning a 64 bit block cipher into a 128 bit block cipher
Almost. It's a Feistel network, except that you encrypt the left half with the right half as the tweak, instead of using a PRF-then-XOR approach. See the left side of Figure 5 of the linked PDF (pg 11). You'll only get a q^2/2^64 security bound, though. (If you were to start with a TBC that had beyond-birthday-bound security, you could instead use a three-round Feistel construction to avoid this problem. But this would probably be far too slow).
Jun
19
comment Turning a 64 bit block cipher into a 128 bit block cipher
The same paper shows that you can construct a 2n-bit TBC out of an n-bit TBC using two rounds, which might be the answer @Maarten_Bodewes is looking for (since a TBC can be used as a traidtional blockcipher). So that works out to be two blockcipher calls plus two 64-bit finite field operations (assuming LRW) or four blockcipher calls (assuming XEX).
May
25
comment How many bits of entropy can I expect from /dev/urandom in iOS?
Once you've collected, say, 256 bits of entropy, you can use that to generate essentially arbitrary amounts of pseudorandom bits that are secure for all practical purposes. CTR_DRBG is a perfectly good way to go about doing this. Concerns over "running out" of entropy are misplaced. Others have put it more elegantly than I can: gist.github.com/tarcieri/6347417, sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers
May
23
comment Encrypt-Mix-Encrypt: Full Diffusion?
There were originally some patent issues (which may or may not have been resolved since, I haven't seen anything definitive). Additionally, EME requires two blockcipher calls per block of input, which slows performance.
May
20
comment Would this method deliver a perfectly non-malleable encryption for at least two blocks?
@Anon2000, First, as Steven says, you probably should be looking for a MAC. But if you're really after non-malleable encryption, then what you want is a wide-block cipher, such as EME or the more recent AEZ with a zero-bit tag and zero-bit nonce (web.cs.ucdavis.edu/~rogaway/aez).
May
3
comment Format preserving encryption FFX
@MaartenBodewes Yes. I edited my answer to expand the acronym out.
Apr
3
comment Required key size for an ideal cipher with a 32 bit block size
I suspect this is a homework question aimed at establishing why we can't construct an ideal cipher for even modest block sizes. asdfhjk: For a cipher to be ideal, you need one key for each possible permutation. So how many strings are in the set {0, 1}^32? How many permutations are there on a set of this size?
Mar
13
comment Block cipher mode with diffusion on ciphertext
You might want to look into OCB. It provides verification in a "strong" sense (i.e., AEAD) with performance not too far off from CTR mode. See web.cs.ucdavis.edu/~rogaway/ocb/news for a portable optimized implementation and web.cs.ucdavis.edu/~rogaway/ocb/license.htm for license info (free in almost all cases).
Feb
13
comment Is Pseudo-Random Generator (PRG) in OpenSSL uniformly distributed?
"Cryptographically Secure, which means it passes statistical tests". To be clear (and I don't mean to imply Security Aficionado is unaware of this issue), Cryptographic security requires much more than that. Standard statistical tests are quick and dirty, and look for very generic types of "non-randomness"; cryptographic security requires outputs to be indistinguishable from random even against computationally intensive tests that are targeted specifically at the algorithm in question.
Feb
5
comment Does using modulo (%) affect quality of randomness?
@tylo Thanks for the catch, I've fixed the error.
Oct
14
comment Key management protocol for end-to-end security on Advanced Metering Infrastructure
This is a bit of a tangent, but if you're interested in learning about what some more sophisticated crypto can do in the specific context of smart meters, you might want to read up on work by George Danezis et al., e.g., www0.cs.ucl.ac.uk/staff/G.Danezis/papers/DFKZSEGS13.pdf.
Oct
3
comment Has there been any cryptanalysis of AES under a non-uniformly distributed key?
@owlstead This is not my area, but it seems to me that key scheduling attacks would be well in-scope here. For example, consider generating an AES-256 key by appending 178 zeros (or whatever) to a uniformly random 80-bit string. The result would (arguably) have enough entropy to be border-line secure against brute-force attacks, but it's my understanding that the key scheduler wasn't designed to handle this level of abuse.
Oct
3
comment Has there been any cryptanalysis of AES under a non-uniformly distributed key?
@TravisMayberry I was using the term "uniform distribution" in the technical sense, i.e., all keys are equally likely. The standard PRP security definition assumes this property of the blockcipher key, and I was wondering if anyone had looked at the question of what happens when this assumption is violated (aside from related key attacks).
Sep
30
comment Bridging the gap between security proofs and “real-world” security
I think that in its current form, this question might be too broad and subjective. This rabbit hole is deep. The range of possible issues includes appropriateness of the attack model (most models assume no timing side-channels exist), the interpretation of what "secure" means (when is it safe to leak plaintext length? Are even the strongest possible order-preserving encryption security definitions "secure enough"?), the assumptions (AES? Good. LWE? Hmm... ROM? Uh...). To say nothing of concrete vs. asymptotic security, a can of worms on its own! Not to mention implementation issues.
Sep
19
comment Authenticating Very Short (Sub-Block) Data
Addendum: I should probably also note that this approach won't protect you against replay attacks. While this is true of authenticated encryption in general, it's a harder problem to solve if messages are too short to include a monotonically increasing counter or some other protocol-level countermeasure. Without knowing more context, it's hard to know what threats you should be concerned with.
Sep
19
comment Authenticating Very Short (Sub-Block) Data
Length-preserving schemes are by definition FPE. But if bandwidth is an issue, you can get very short authenticated ciphertexts by using encode-then-encipher (seclab.cs.ucdavis.edu/papers/Rogaway/encode.pdf). If you pad your 64-bit payload with 0s until it's 128 bits long and encrypt using AES (in ECB mode, no IV), then you can check authenticity by verifying that the padding is all 0s when you decrypt. Some warnings: (1) an attacker will be able to learn if a message is repeated (2) this only works if messages are significantly shorter than the AES block length (128 bits).