9,566 reputation
12347
bio website github.com/CodesInChaos
location Frankfurt, Germany
age
visits member for 3 years, 1 month
seen 29 mins ago

Sep
24
comment Achieving 256-bit encryption strength with PBKDF2 - HMAC-SHA1
For the "compute part of the output cheaply" issue I recommend using HKDF-Expand as second step, that way one can produce arbitrarily sized output at little cost.
Sep
24
comment Why is RSA encryption significantly faster than decryption?
Encryption and signature verification are much faster than decryption and signing when using RSA. The public exponent e is small (typically 17 bits) and the private exponent d (~1024 bits) is large leading to a cheaper calculation for $m^e$.
Sep
24
comment Achieving 256-bit encryption strength with PBKDF2 - HMAC-SHA1
Are you expecting pass*word*s with ~240 bits of entropy? You only get that much entropy with an epic pass*poem*.
Sep
23
comment What is the security loss from reducing Rijndael to 128 bits block size from 256 bits?
@owlstead It certainly seems attractive to use it for disk encryption, it's a natural tweakable blockcipher with large blocks. XTS mode is a bit ugly, and 128 bit blocks are a bit narrow, so AES-XTS doesn't look so good to me.
Sep
23
comment Extracting only the entropy
If you manage to estimate entropy, then you can still simply truncate the hash to the estimated entropy. Entropy estimation and extraction are mostly independent.
Sep
23
comment Using Whirlpool hashing function to encrypt data
But of course HMAC causes another factor 2 slowdown of an already slow construction.
Sep
23
comment Using Whirlpool hashing function to encrypt data
Your operation can't be decrypted in the first place. So it's not even encryption.
Sep
23
comment Using Whirlpool hashing function to encrypt data
Your specific mode looks crazy. At best it's similar to ECB, which is a very weak block cipher mode. Your construction is actually fatally broken for some hashfunctions, since the DataBlock XOR hash step might interfere with their feed-forward operation.
Sep
23
comment Where is the S-Box generated in Rijandel/AES?
When using AES-NI instructions it's not even hardcoded in software, it's hardcoded in hardware :)
Sep
23
comment Where is the S-Box generated in Rijandel/AES?
I didn't listen to the talk, but perhaps you're confusing round-keys and s-boxes. Round-keys can be computed on the fly or precomputed. In the latter case, they're computed during key setup.
Sep
23
comment Extracting only the entropy
Compression gives you an upper bound, but for security you need a lower bound. Generic compression routines will probably overestimate entropy so much that they're useless.
Sep
23
comment What is the security loss from reducing Rijndael to 128 bits block size from 256 bits?
Block size doesn't affect security much, for most modes of operations the only consequence is that you should encrypt significantly less than 2^(b/2) blocks of data using a single key. We currently encrypt nowhere near 2^68 bytes under one key, so 128 bit blocks are fine.
Sep
23
comment What is the security loss from reducing Rijndael to 128 bits block size from 256 bits?
There is no reason for matching key and block size. You can't really compare Rijndael with ThreeFish, the latter was designed as a building block for a hashfunction (Skein) and its design choices reflect that goal.
Sep
23
comment md5sum collision question
The block size of MD5 is 512 bits or 64 bytes not 64 bits.
Sep
23
comment Assuming a 1024qb quantum computer, how long to brute force 1024bit RSA, 256bit AES and 512bit SHA512
AFAIK you need about 2 qbits per RSA modulus bit to run Shor's algo which then breaks RSA with negligible cost. So you'd need a ~2048 bit QC to break RSA-1024.
Sep
23
comment Extracting only the entropy
@Blaze It's impossible to estimate the entropy of an input without context, so you can't limit the output size to the entropy, no matter which extractor you use.
Sep
23
comment Extracting only the entropy
Why do you want to avoid hashes?
Sep
23
comment Is it safe to use GZIP to avoid padding related attacks
Padding oracles are just one example of a larger class of attacks where the decrypter leaks information about the plaintext. I bet that gzip by itself is already enough of an oracle, with similar capabilities as a padding oracle.
Sep
21
comment With a true random number generator at hand, how to implement one-time pad?
You output the pad, transfer it through some secure channel (out of scope), and then simply xor it with the message to encrypt/decrypt. With which part do you have a problem?
Sep
20
comment Is it safe to use GZIP to avoid padding related attacks
1) I'd use a deterministic padding scheme 2) It's essential to apply a MAC after encryption. Else active attacks, like padding oracles will break it.