If you believe that "don't roll your own crypto" is some kind of absurd mantra the security industry uses to keep us in business, I recommend that you roll your own crypto, and keep us in business.
How far should we take that maxim? It implies that no one should ever attempt this, but that leads to nothing new (unless you are first recognised as a crypto guru -- but how could you become one?). I think it's worth drawing a distinction between the algos/maths and attempts at implementations. Otherwise we wouldn't have things like OCaml-TLS and others. http://openmirage.org/blog/introducing-ocaml-tls
Maybe people can show new stuff they make on HN etc before using it in their apps.
That seems ridiculous for 2 reasons. First, ciphertext is ciphertext. They'd probably be able to determine it's a block cipher and what the block size is, but that's about it. They're not going to be able to tell AES ciphertext from 3DES ciphertext if they're both set to use the same block size. There's no point "obscuring" the fact that you're using AES. Second, if you're assuming the NSA seriously has the capabilit…
First, ciphertext is ciphertext. They'd probably be able to determine it's a block cipher and what the block size is, but that's about it. You can tell mode somewhat reliably (I've hit 75% confidence or so) by the entropy content of the ciphertext, and I've never done a Markov chain longer than a native word so I'd assume that gets better the longer your chain is. I would also assume people much smarter than me have…
I believe it is considered a significant break in a block cipher if you can distinguish messages encrypted via that cipher against random bits constructed in a similar way (i.e. constructing an adversary such that it has a non-negligible advantage in the PRF security game against the family of functions for the block cipher).
If you believe that "don't roll your own crypto" is some kind of absurd mantra the security industry uses to keep us in business, I recommend that you roll your own crypto, and keep us in business.
How far should we take that maxim? It implies that no one should ever attempt this, but that leads to nothing new (unless you are first recognised as a crypto guru -- but how could you become one?). I think it's worth drawing a distinction between the algos/maths and attempts at implementations. Otherwise we wouldn't have things like OCaml-TLS and others. http://openmirage.org/blog/introducing-ocaml-tls
Implementations are even more sensitive to tiny bugs with huge consequences than algorithms. It's fine for people to write their own implementations if they're never used, but anything that will be used needs a large number of experts and a large amount of time before it should be trusted.
Thank you for the link and the review. I start my CS degree in the Fall; i hope i can start and finish this before then.
For the love of all that is sacred, take advanced math and linear algebra.
Thank you for the admonition. I am double majoring in CS and Philosophy for a specific reason; i want to manage devs and IT wizzards. I want to function as an informed go between for the sweat stainless white collars and the yellowed white collars that do the work. I love the theoretical space of design and networking, but i have very low expectations of my actual capabilities at the nuts and bolts. I am a [failed] writer and indy movie producer, but i want to be 'part of your world'. I have been trying to self educate, but it is not simple with no mentor. I see uni as a chance to be around people who are smarter than me as well as make time to write the novels and short stories that make me happy. So i am going to start in CS and Philosophy, audit engineering courses and IR courses, then switch majors to whatever seems appropriate. I am a bit older than your typical freshperson, and i am building a trajectory for post-grad, but really i am button mashing like it's StreetFighter. ANy advice is appreciated; i will look into the Maths Degrees.
So I think it comes down to whether the root > I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. is a sound advice. I disagree with this advice strongly. Tinkering around with cryptography can teach you a lot. Especially if you are not a top expert. Furthermore, I described a relatively simple protocol that monotonically increases the secu…
I described a relatively simple protocol that monotonically increases the security of a communication Careful. Encryption is decryption, remember. Do any of the rounds of CC undo any of the rounds of KC? Can you verify that bits that were correlated in PT and uncorrelated in KC are still uncorrelated in KC + CC? Does CC change the entropy content of the resulting message? (If it decreases it you have a problem, and m…
By definition, if CC doesn't know the key and doesn't search to key space of KC and it reduces the security of KC then CC breaks KC.
If you believe that "don't roll your own crypto" is some kind of absurd mantra the security industry uses to keep us in business, I recommend that you roll your own crypto, and keep us in business.
Schneier's Law comes to mind "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." https://www.schneier.com/blog/archives/2011/04/schneiers_law...
I would compare it to a writer's inability to spot typos in something they wrote themselves. Probably, if the same algorithm was written by someone else, they could tear it apart easily.
How far should we take that maxim? It implies that no one should ever attempt this, but that leads to nothing new (unless you are first recognised as a crypto guru -- but how could you become one?). I think it's worth drawing a distinction between the algos/maths and attempts at implementations. Otherwise we wouldn't have things like OCaml-TLS and others. http://openmirage.org/blog/introducing-ocaml-tls
Maybe people can show new stuff they make on HN etc before using it in their apps.
HN is not and never will be an appropriate stage for cryptographic review.
If you believe that "don't roll your own crypto" is some kind of absurd mantra the security industry uses to keep us in business, I recommend that you roll your own crypto, and keep us in business.
Schneier's Law comes to mind "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." https://www.schneier.com/blog/archives/2011/04/schneiers_law...
The output of KC is not necessarily completely random. It can contain some metadata. Like "encrypted with KC4096bits, initialization vector is 490282348992489, length of ciphertext is 26728 bytes". When you pass this through a bad cipher it may create a characteristic fingerprint.
I think you confuse cipher with protocol. To make it clear: for me a cipher is a bijective function on arrays of a predefined length.
What do you propose doing with the initialization vectors then? Afaik, all commonly used encryption algorithms have those, for good reason too.