1,190 reputation
619
bio website ethanheilman.tumblr.com
location Cambridge, MA
age 31
visits member for 2 years, 9 months
seen 2 days ago

Jan
31
answered Encryption/ciphers/codes in Chinese
Jan
30
comment Designing a key expander out of ciphers
I agree that it is not a particularly fair vulnerability (I did not ask for protection against this scenario), but it is certainly one that might be exploited in practice given that key reuse is common in certain contexts. There are two ways to secure your protocol against this attack: (1). encode the name of the ciphers used in the first bits of the key so that if you switch the ciphers you change the key (this chunk of the key is no longer protected), (2). generate a random IV that is never used and xor it with the key (only secure as long as the IV is never reused).
Jan
30
comment Designing a key expander out of ciphers
This scheme is secure as long as you never use the same keys with a different set of ciphers. For instance using $k$ with ciphers: $A, B, C$ and then reusing $k$ with ciphers: $E, B, C$ (consider the case where $E$ produces exactly the same output as $A$ except for the last bit). Given two nearly identical sets of ciphertexts mapped through $f$ we should be able to learn some bits of the key $k$, as long as $f$ is not a random oracle (I am still not completely familiar with resilient functions, but if resilient function are not vulnerable in this way they are as powerful as Random Oracles).
Jan
27
comment Designing a key expander out of ciphers
Lets see if I understand. We generate $n$ ciphertexts by encrypting the key $k$ with itself over all the ciphers $cipher_{0}(k,k) .. cipher_{n}(k,k)$. We use these $n$ ciphertexts to generate a function $\mathbb{F}_q$ which we use to generate the value $y$. If I got all that correct, my next question is how to you encrypt $y$ under $k$. Do you use all the ciphers? How do you compose the ciphers? Do you break $y$ into $n$ pieces and encrypt each one of the pieces?
Jan
26
comment Designing a key expander out of ciphers
I'm not sure I understand, you apply the resilient function $f$ to 'the ciphertexts' but how are these ciphertexts being generated? How are you encrypting $y$, are you using all the ciphers? It's interesting (learning about resilient functions now) but I don't fully understand all the steps.
Jan
25
comment Designing a key expander out of ciphers
I see your point, I think that what you describe is what happened when I was copying the formulas from my notes. An implementation should probably have some test cases to check for that sort of mistake.
Jan
25
revised Designing a key expander out of ciphers
fixing serious flaw
Jan
25
comment Designing a key expander out of ciphers
+1 Good catch! You are correct and a lesson for us all about hobby cipher schemes. Especially troubling because I remember worrying about this exact case when I was coming up with this. I believe I have fixed it now(new readers can see look at the old revision to see my change), but I will be thinking this over to see if I missed anything.
Jan
25
comment Can nesting different ciphers with different keys ever decrease security?
In fact even if the keys are not independent and there are methods to deterministically generate the keys from a single base key, such that one can compose the ciphers and security is never reduced. Shown here: crypto.stackexchange.com/questions/741/…
Jan
12
comment Is it possible to distinguish a securely-encrypted ciphertext from random noise?
Assuming a randomly chosen key and a randomly chosen plaintext why is it impossible to prove that no distinguisher exists? Has this been proved?
Jan
9
revised suggestions for cryptography projects for an ece 3rd year student
disclaimer2
Jan
9
answered suggestions for cryptography projects for an ece 3rd year student
Jan
9
comment Why programming languages don't provide simple encryption methods?
I would argue that protocols are not easy to implement either but our discussion is getting rather off topic (off question). Would you be willing to open a question called "Is it better to have one standard protocol for each security need or should a diversity of protocols be implemented for a given security need?" I would be happy to provide a full length answer to such a question.
Jan
9
comment Why programming languages don't provide simple encryption methods?
While what you say has wisdom the crypto community has taken the opposite approach. Create one standard that everyone reviews, checks, vets, attacks, researches. Use that standard everywhere. For example see the selection of AES, or the current SHA3 contest. Some designers have suggested that NIST select the top three hash functions for SHA3 rather than only one. The argument against this is that if a protocol supports the top 3 and one of them is broken an attacker can request that the protocol use the broken function (tripling the chance of a break).
Jan
6
comment Is it possible to create an easy to use encryption/decryption method that will never be comprimised?
I have no problem with Rijndael (AES) per se, what I have a problem with is that the library is expecting the engineer to turn a secure block-cipher (AES) into a secure crypto-system (AES is fine but it needs all the other stuff: padding, authentication, IV generation, a chaining mode). The default crypto libraries that an engineer encounters should operate at the level of crypto-systems not at the level of primitives. For example bcrypt does a decent job of this with hashing passwords (with some reservations). The default interface is BCrypt::Engine.hash_secret(password, password_salt).
Jan
6
comment Is it possible to create an easy to use encryption/decryption method that will never be comprimised?
I think we can set the bar pretty high in terms of brute force. No one is concerned that AES will be broken due to brute forcing the key. In fact it is quite easy to create a crypto-system with a key so large a computer the size of the universe couldn't brute force it. For instance using all the atoms in the universe ($10^82$ atoms) as computers capable of computing 1 trillion keys a second, one could brute force roughly 2^314 keys a second. To brute force a 512-bit key would take roughly $10^{52}$ years (far far longer than the lifetime of the universe).
Jan
6
comment Is it possible to create an easy to use encryption/decryption method that will never be comprimised?
I agree with your analysis that given infinite computational resources such a scheme, outside of a OTP, would likely be compromised. Generally success of a crypto-system is defined by showing that the best possible attack is brute forcing the key-space. I think the more interesting question is if such a scheme is possible given key-space bounded compute time (a more typical definition of security). The most interesting question, to me, is how can we increase our trust in crypto-systems given that non-cryptographically trained engineers will be (mis)using them (fool proof security).
Jan
6
comment Why programming languages don't provide simple encryption methods?
"Any canned solution is going to be compromised eventually." I strongly disagree with this statement. A well thought out, tested and understood standard that has undergone extensive review by the crypto community has a much better change of avoiding compromise than a system designed by a single engineer using a fairly low level library. If languages are serious about security as a feature such secure crypto-systems should be the easiest option available to a engineer. As a general rule I see no reason excuse for not designing libraries to be secure by default, most secure option is easiest.
Jan
5
comment Why programming languages don't provide simple encryption methods?
I think David Schwartz gave a decent partial answer to "Why programming languages don't provide simple encryption methods?", but it concerns me that the question assumes that there is a good reason why programming languages don't provide a simple secure encryption system rather than insist that users roll their own. I don't have a good answer why they don't but I'm using this question as a soapbox to insist that they should (I think this was probably the original intend of the OP).
Jan
5
comment Why programming languages don't provide simple encryption methods?
Creating your own encryption library is a recipe for distaster. Most people using encryption do understand exactly what they want so providing an easy option that doesn't default to ECB and includes authentication and padding turned on by default would be extremely helpful. I'd be curious to see any libraries that do encryption in a simple and secure manner (simplicity and security are proportionally linked in my experience). I'm not saying they don't exist, I'd really like to discover that such libraries are common and available for most languages, I just haven't run into them.