1,256 reputation
722
bio website ethanheilman.tumblr.com
location Cambridge, MA
age 31
visits member for 3 years, 2 months
seen Sep 7 at 21:25

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
26
awarded  Taxonomist
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
revised Security of simple xor and s-box cipher?
added 988 characters in body
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
revised Security of simple xor and s-box cipher?
updating status of answer
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.
Nov
23
revised Security of simple xor and s-box cipher?
This answer no longer applies to the question since the scheme proposed in the question has be drastically changed.
Nov
23
comment Security of simple xor and s-box cipher?
The above scheme does not use multiple rounds but rather uses only one round with a different round key per message block. A multiple round scheme would have the same the same message block be enciphered by more than one round key. You may have conflated CBC with rounds. I think you should probably abandon the CBC stuff until you have a secure block cipher and then figure out how to use that secure block cipher in a CBC mode.
Nov
23
answered Security of simple xor and s-box cipher?