Reputation
2,268
Top tag
Next privilege 3,500 Rep.
Protect questions
Badges
9 24
Newest
 Custodian
Impact
~25k people reached

1d
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).
Aug
23
comment Efficiently map $2^n$ unique 64-bit vectors to $2^n$ $n$-bit vectors where $n < 64$?
I'm not sure what you're arguing. For concreteness, let's use the example I gave earlier, and suppose that, say, n = 63, both x1 and x2 are at least 2^63, x2 = DES_K(x1), and suppose that y = DES_K(x2) < 2^63. My understanding of your proposal is that both x1 and x2 would map to y because this is the first value in [0, 2^63) we reach by repeated application of DES_K, regardless of whether we start from x1 or from x2. If this is incorrect, could you please clarify how the mapping is computed?
Aug
23
comment Efficiently map $2^n$ unique 64-bit vectors to $2^n$ $n$-bit vectors where $n < 64$?
The "cycle-walking" method wouldn't work here because your target space is not your source space. For example, you could have two inputs X1 and X2 in your source space such that AES_K(X1) = X2 (it would make slightly more sense to use DES here, but same thing would happen). In this case, X1 and X2 would then map to the same point in your target space, unless X2 was already in it.
Aug
5
comment How many degrees of freedom up my sleeve?
You might find the (satirical but still substantive) paper "How to manipulate curve standards: a white paper for the black hat" interesting; it addresses this question in the context of ECC parameters. PDF: eprint.iacr.org/2014/571.pdf
Jul
21
comment Lowest number challenge scheme
This is Yao's Millionaires' Problem: en.wikipedia.org/wiki/Yao's_Millionaires'_Problem
May
28
comment AES/CBC fixed Initial vector use-case
Using a fixed IV will also leak the information about the length of any shared prefixes. Also note that CBC won't stop someone from tampering with the cookie so that it decrypts to something that you don't expect, and if an attacker can guess at some of the cookie's contents, he will have a degree of control over what this is.
May
22
comment Can you determine an unknown value when it is combined with a known value and you are given the resulting hash?
If this is motivated by a homework question asking about the security of H(K|M) as a MAC (for hash function H, key K, and message M), you should consider the possibility that an attacker may not need to learn K in order to produce a forgery. Think about how SHA256 works internally.
May
22
comment Simple way to extend AES to 256-bit block size
possible duplicate of Is it possible to construct a secure block cipher of size $2n$ given a secure block cipher of size $n$?
May
4
comment How do I produce a stream of secure random numbers from AES-Counter mode?
Updating the nonce won't let you beat the birthday bound. Additionally, the 2^64 bound is when the provable security of CTR becomes worthless; if you want the security to remain strong (say, by limiting an adversary's advantage to 2^{-40}), then you'd need to stop at 2^{44} bits. Not that this is usually a problem!