1,190 reputation
619
bio website ethanheilman.tumblr.com
location Cambridge, MA
age 31
visits member for 2 years, 9 months
seen Apr 18 at 0:02

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
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.
Jan
4
comment Why programming languages don't provide simple encryption methods?
My understanding is that the OP is asking for a simpler interface in which he doesn't have to figure out how to generate an IV, choose the block cipher to use, and manage streams. Note that IV management can decide the security of a system as happened in the BEAST attack. Does ICryptoTransform provide padding, authentication, chaining? Is it running in ECB mode? How does it handle abrupt interruptions in the input stream? Wouldn't a nice (utf-8string, key) => authenticated non-mutatable ciphertext library prevent more errors than not? Shouldn't it be something we are striving toward?
Jan
4
comment Why programming languages don't provide simple encryption methods?
There is a general rule that when an engineer designs a crypto system, that system is insecure. Creating libraries that encourage the design, rather than the use, of cryptosystems is exceedingly dangerous. I'm not sure what you mean by the statement: "The reason is that if it is simple to use then it is simple to use the decryption method to easily decrypt." I don't think anyone is proposing simplifying away the key, nor do I think the inclusion of a key causes the needless complication seen in crypto libraries. I see no reason why one can't design a simple secure crypto library.
Jan
3
comment Why programming languages don't provide simple encryption methods?
Can anyone provide examples of security failures that resulted from the lack of ease of use of Encryption libraries?
Nov
28
comment Where is the proof of security of Diffie's cipher?
Can something be perfectly secure and still vulnerable to a known-plaintext key recovery?
Nov
23
comment Security of simple xor and s-box cipher?
+1, this is an excellent answer, thanks Thomas.
Nov
23
comment Security of simple xor and s-box cipher?
Probably a question on notation would be in order but let me try to provide a concise explanation here. $E : K \times M \rightarrow M$ means $E$ is a function that uses $K$ to map values of $M$ to other values of $M$. That is the encryption function $E$ uses a key $K$ to map a message to another message with message-space $M$ where messsage-space is the space of all possible messages. It is a notational definition of encryption.
Nov
23
comment Security of simple xor and s-box cipher?
Problem: nothing is getting mixed outside of these $16$-bit chunks (a bit in the first $16$-bits never effects the outcome of a bit in any other chunk). That is, the block cipher is really a $16$-bit block cipher. You can brute force and attack each of these $16$-bit chunks. To make it stronger we need diffuse the bits outside of your chunk. You have key substitution network, but what you really want is a key permutation/substitution network ( en.wikipedia.org/wiki/Substitution-permutation_network ).
Nov
23
comment Security of simple xor and s-box cipher?
If your message block size is $256$-bits and your s-box size is $16$-bit what exactly is $S[M]$ doing (looking up $16$-bit chunks of $M$ in $S$?
Nov
23
comment Security of simple xor and s-box cipher?
How do you combine these rounds? $C_n = S[K_0 \oplus M_n] \oplus S[K_1 \oplus M_n] \oplus ... S[K_r \oplus M_n]$ ?
Nov
23
comment Security of simple xor and s-box cipher?
@Polynomial - Consider the case in which you only have one message block, $C_n = S[K_0 \oplus M_0]$. $S$ is invertible and so we are back to the known plaintext attack. You need the second xor of the key to prevent an attacker from inverting S ($C_n = S[K_0 \oplus M_0] \oplus K_0$) . The approach you should take is, to build a secure block cipher that only processes one message block. If it isn't secure with only one block it is unlikely to be secure with more than one block.