Stephen Touset

1,251 reputation

215

bio	website	touset.org
	location	San Francisco, CA
	age	29
visits	member for	7 months
	seen	1 hour ago
stats	profile views	14

Cyclist. Rubyist.

	1,251 reputation	bio	website	touset.org	visits	member for	7 months
215 badges		location	San Francisco, CA		seen	1 hour ago

summary answers questions tags badges favorites bounties reputation activity

235 Actions

suggestions reviews revisions comments badges posts accepts all

Jan 7	awarded	Organizer
Jan 7	revised	Break double encryption edited tags
Jan 7	revised	Break double encryption edited tags
Jan 4	comment	AES 128bit round level recommendation Note that Schneier suggest that NIST update the AES spec to use a greater number of rounds. Not that individuals should reimplement their own higher-round versions of AES. Note also that he doesn't recommend existing implementations move away from AES-256. Let the cryptographers do what cryptographers do best — when there's genuine cause for alarm, you will hear about it.
Jan 2	comment	Benefit of combining classical substitution ciphers with modern cryptography Why wouldn't it be? It's the exact same construct.
Dec 22	answered	AES-GCM and its IV/nonce value
Dec 21	comment	AES 128bit round level recommendation Can you do this without exposing yourself to the weakened AES-256 key schedule? That's the whole reason Schneier advocates using AES-128 in the first place, as well as increasing the number of rounds of each variant.
Dec 20	answered	AES 128bit round level recommendation
Dec 20	answered	Reason(s) for using a KDF for encryption keys
Dec 19	comment	Why is asymmetric cryptography bad for huge data? Not to mention, asymmetric encryption with a 2,048-bit key isn't necessarily more "secure" than symmetric with a 256-bit key.
Dec 19	comment	What is an easy method of proving that a cryptographic oracle attack is possible? I don't think you can do any better than checking timings with a large enough sample size to discern signal from noise (assuming nothing obvious, like error codes). Which obviously is going to be a statistical test and not an absolute one.
Dec 19	comment	Double Encrypting with two different keys What if they log in in a different order? Why not just generate two appropriate-length keys, give them to each user, and XOR the two for the "real" key? In any case, it looks like you're trying to reinvent secret sharing. Please be careful — you appear to be homebrewing your own extremely complicated cryptographic protocol. A complicated but badly-implemented protocol is going to be substantially more vulnerable than a simple but correctly-implemented one.
Dec 18	comment	Double Encrypting with two different keys Also, this only really affects brute force attacks, and brute force attacks are essentially the least of your concerns once you have already selected an appropriate key length (e.g., 128-bit or 256-bit symmetric keys).
Dec 18	comment	Double Encrypting with two different keys The effort to brute force any double encryption scheme is `O(2^(len(k1)) + 2^(len(k2)))`. If the key lengths are equal, it is only a factor of two more difficult to brute force, which is an extremely minor increase in security. If the key lengths are unequal, it is more difficult by less than a factor of two of the length of the longer key.
Dec 18	comment	Double Encrypting with two different keys Please also consider the advice from the other thread that you should absolutely not be trying to use cryptographic primitives on your own. They are trivial to use insecurely and exceedingly difficult to use correctly. Libraries like KeyCzar and NaCl exist that perform the necessary computations for you, and you should absolutely use one of these.
Dec 18	comment	Double Encrypting with two different keys Encryption is reversible so collisions are not an issue, and due to the meet-in-the-middle attack discussed in the earlier answer, it is generally not considered to be stronger (it's equivalent, effectively, to using a key that is a single bit longer).
Dec 18	comment	Double Encrypting with two different keys Also, it wasn't mentioned there, but your key generation is very weak. You should use either a key generated by a cryptographically random source of entropy (e.g., /dev/random), or at the very least use a key stretching function like PBKDF2 with an appropriately-calibrated number of iterations, and a cryptographically random salt.
Dec 18	comment	Double Encrypting with two different keys You already asked this, and it was already answered.
Dec 17	comment	creating a small number from a cryptographically secure random string Excellent answer.
Dec 17	comment	AES Key Length vs Block Length What do you mean by 26 plaintexts and 26 ciphertexts? That would only be the case for a single-character message, for which there is one permutation (the identity) and 26 possible substitutions.