1,276 reputation
722
bio website ethanheilman.tumblr.com
location Cambridge, MA
age 32
visits member for 3 years, 4 months
seen Nov 9 at 20:46

Jan
2
comment Why programming languages don't provide simple encryption methods?
You have a source for the statement that "it turns out that the AES has a back door that the NSA has access to"?
Sep
30
comment Could one construct a cipher that is secure for friendly parties to use but insecure for hostile parties?
@user4982 The Soviets did the same thing with GOST (different s-boxes to different people, some believed to be backdoored). 4C Entity thinks like the USSR?
Feb
20
comment Why programming languages don't provide simple encryption methods?
I am asking for serious failures in security that results in physical or financial damage. Such examples would make the case for simple easy to use packaged encryption in much the same way that firms which did not salt their passwords and had massive password exposures helped the security community "raise the bar" on password hashing standards.
Oct
23
comment Because the algorithm is known, it is no longer a trade secret
The NSA has several secret ciphers, called SUITE A (BATON being one of the most well known). SUITE A ciphers (not publicly revealed) are considered the most secure by the NSA (although a few type 1 ciphers are public). That is not to say the ciphers have not be subject to review, many many cryptographers work for the NSA and have attempted to break these ciphers. That being said, I'd still prefer AES256 to BATON if my life depended on it. en.wikipedia.org/wiki/BATON archives.neohapsis.com/archives/crypto/2000-q4/0028.html en.wikipedia.org/wiki/NSA_Suite_A_Cryptography
Oct
12
comment Could the Enigma algorithm be classified as a Feistel network?
@bob - Yep you are correct. I had always heard that the reflector was unique to enigma (since the germans patented it) and assumed the plugboard while necessary to security was a rather common feature on rotor machines at that time. Researching this further I realize I was wrong, reflectors were quite common (for example the M-325 had a reflector) but I can find no mention of plug boards prior to the enigma (although that doesn't mean there were none). quadibloc.com/crypto/ro020404.htm
Oct
2
comment Could the Enigma algorithm be classified as a Feistel network?
Also FYI The trick that made enigma so powerful was not the rotators changing position (since that was common of rotor machines of that time period hence the term rotor), it was the reflector that reflected the character back through the rotors. see en.wikipedia.org/wiki/Enigma_machine#Reflector The reflector also introduced a weakness into enigma. Namely that a character could never be encoded by itself.
Jul
24
comment Is there a way to break this encryption?
Using the hash of the file as a public IV is extremely dangerous since it allows an attacker to try plaintexts and detect if they match. XCE would need to add randomness to plaintext to avoid this, but why not just use a random IV instead.
Jul
24
comment Is there a way to break this encryption?
@xce Under option 2 there is no way to decrypt the file since the decrypter doesn't have access to a hash of the file it can't generate the same random sequence and decrypt the file.
Jul
24
comment Designing a key expander out of ciphers
Edited post to add I just found a weakness in this.
Jul
3
comment Are there any simple and yet secure encryption algorithms?
Probably the only "a priori secure" function we have is a OTP.
May
22
comment Order of cascaded ciphers
Thanks, somehow I missed that.
Feb
10
comment Why do we need asymmetric algorithms for key exchange?
In light of recent break-ins at root-level Certificate Authorities an effective argument could be made that Kerberos while less efficient is actually more secure than PKI because: (1). revoking trust is easier in Kerberos and (2). that Kerberos'es "online" requirements increase the complexity of attacks. Consider the case in which someone wishes to intercept a session secured by Kerberos. An impostor kerberos must be set up and it must quickly issue valid tickets for various domains or else cause very visible failures.
Feb
6
comment Encryption/ciphers/codes in Chinese
+1 Very interesting/good catch. I had just assumed that such a mapping would be reversible. I know this defeats the purpose of the exercise but what about translating a word into a phonetic alphabet (say english) and then using rot13. As a teenager me and some of my friends used online translation engines such as babel-fish as a form of code.
Feb
1
comment Encryption/ciphers/codes in Chinese
Chinese computer users use standard keyboards. They construct the characters by typing latin letters (this system is called en.wikipedia.org/wiki/Hanyu_pinyin ), this process is reversible. (1). Write the chinese sentience in latin-alphabet using the Hanyu-Pinyin system, (2). apply rot13/vigenere, (3). type the result. It should be similar to your system but easier for users since it doesn't require doing UTF8 table look ups.
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
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.