| “break my cipher”-collection-post Posted: 01 Oct 2018 01:42 PM PDT The purpose of this post is to provide a space for learning. "It's easier to prove the [Riemann Hypothesis] than to get someone to read your proof!" - unknown Designers get a chance that somebody will actually honor their ideas with a review that may teach them about issues that they may not have thought about. Because even if they come up with something secure, the above quote sums up what will happen. I remember a conversation in 1991 with Brian Snow, a highly placed senior cryptographer with the NSA. He said he would never trust an encryption algorithm designed by someone who had not "earned their bones" by first spending a lot of time cracking codes. That made a lot of sense. I observed that practically no one in the commercial world of cryptography qualifies under this criterion. "Yes," he said with a self-assured smile, "And that makes our job at NSA so much easier." A chilling thought. I didn't qualify either. - Phil Zimmermann Possibly even more interestingly, upcoming cryptanalysts get a chance to attack ciphers that are neither intentionally broken to demonstrate a certain attack, nor completely out of their league (attacking AES as a beginner is a useless waste of time) nor already broken by somebody else (which is less motivating than the chance to become the first). To ease analysis a strict format of all proposed ciphers will be required, which will hopefully encourage more participation. Rules for everyone - There is one top-level-post for general discussion, aside from that all top-level-posts are reserved for presentations of primitives that follow the below format.
- All cryptographic primitives are acceptable, so even though the majority of posts will most likely be ciphers, hashfunctions are for example fine as well.
- Don't be under the illusion that anything here would hold up to proper cryptanalysis by nation-state-attackers, just because it didn't get broken here by more or less experienced people in their free-time.
- Depending on the volume of posts this post may be replaced with a new one every couple of months. Re-posting comprehensible but unbroken ciphers with a link to the previous post will be encouraged in that case.
Rules for cryptanalysis - Create a child-post for every distinct attack you find.
- If you spend a significant time trying to break a primitive and failed, please post that as well together with everything you consider notable; a post "I tried to break this for 2 hours and failed" is still more useful than none as it provide guidance to which primitives might still be low-hanging-fruits and which are more likely to be challenging.
- Feel free to point out issues that are not relevant to the security-claims but could still bite people who would use it for real, as long as those issues have not been either mentioned or acknowledged in previous answers
- If your attack is complicated, you are encouraged (but not required) to write it down elsewhere and link to it if that helps readability (for example because of the support that LaTeX has for math).
- Even if the primitive is a mess, show respect for the attempt: „Wer kämpft kann verlieren. Wer nicht kämpft hat schon verloren" - "He who fights can loose. He who doesn't fight has already lost"
Rules for posting a primitive For every cipher (or other primitive) create one top-level post, which must have the following structure and include all listed points. Not following these rules might get your post removed (if you don't know where to host code and the description or have any other questions ask in the questions-thread in this post; also look at existing posts to get some idea for the intended structure): - Name: some name for the cipher (makes talking about it simpler, don't go too crazy here)
- Designer: Name of the designer and whether that is you (Posting a primitive of somebody else is generally discouraged, but may be acceptable under special circumstances)
- Kind of primitive: What kind of primitive are you presenting? A block-cipher, stream-cipher, hash-function, MAC, whatever?
- Pen and Paper: "yes" or "no". Whether your primitive is intended to be usable without computers
- Security-claim: What notion of security does your primitive intend to provide? (For context: In theoretical cryptography it is sometimes harder to come up with a sensible notion of "secure" than it is to come up with a protocol that provides it.)
- Security-level: How much security (in bits) does your primitive intend to provide? n bit of security means that breaking it takes at least 2n operations too break. Modern primitives will usually want to have this at 128 bit.
- Overview: Describe in a couple of sentences the basic ideas behind your ciphers, to give readers a rough idea what to expect. Interesting information could for example be that your cipher uses a Feistel-structure with an ARX-round-function.
- Link to complete description: as the title says. This should link to a full description of your cipher that would allow anyone to implement it on just that document.
- Link to implementation: A link to a software-implementation of your cipher in a not too obscure programming-language in an easy to use format; preferably a git-repository that can be cloned. (Use you own judgement for which languages are too obscure, but rest assured that if you use malbloge nobody will read it.)
- Intended parameters: If your cipher is allows different parameters (for example round-count) the specific parameters that you believe to be secure.
Additionally you may add the following points: - Bounties: If you offer bounties for breaks (which is by no means even remotely required!), you may list them here with a precise definition for the circumstances under which you grant them.
- Previous Analysis: Whether somebody already looked at the cipher, what they found and what you yourself already tried.
- Promising attack-vectors: If you have an idea for some kind of cryptanalysis that might yield fast results, feel free to mention them
For everything else (for example the story of the cipher), add an answer to your top-level-post to keep that one short and to the point. (If the story is interesting, it may be double the karma for you! ;-)) Once you've done that, be prepared to answer open questions and acknowledge any attacks somebody might find. Be open to any issues others might find and try to learn from them instead of insisting on riding a dead horse. Tips for designers The following are not mandatory rules but you might still want to follow them: - Using round-based primitives makes analysis much easier and allows to quantify margins and alike. If you want to get good replies, this is most likely the way to go.
- Side-channel-attacks are a thing. You can probably trust that bitwise operations (and, or, xor, shifts, rotations) and addition are safe to use, but almost everything else has the potential to leak information making your cipher immediately very hard to use safely in the real world, even if it was secure. Note that this means that s-boxes are usually a very bad idea.
- Boasting about your new cipher being the greatest and selling it to some secret service will only get you laughed out as a crank and then ignored. Show some humility and assume that your cipher is insecure so you can be proud if it isn't shredded in the first couple of days and don't have to get sad if it doesn't.
- If you want to design a cipher, block-ciphers are sufficient building-block that can be easily crafted as Feistel-ciphers or Substitution-permutation-networks.
- Pen-and-paper ciphers are an interesting topic without too much research and giving them a try is very much encouraged. But: If you believe that they are still relevant for actual use these days, think about how suspicious it is to have a smart-phone on you that is capable of encrypting more text in a couple of seconds than you will read in your entire live. The answer will probably be something like "not at all", which happens to be more or less the answer for how useful pen-and-paper-crypto is in real-life. Of course this doesn't mean that they aren't very exciting from an academic perspective, which is a totally valid reason to invent them. Just don't misunderstand their relevance.
submitted by /u/F-J-W [link] [comments] |
| Boffin: Dump hardware number generators for encryption and instead look within Posted: 01 Oct 2018 05:07 PM PDT |
| Re-Implementing Cryptographic Ciphers Posted: 01 Oct 2018 03:48 PM PDT Hi, I have been building some crypto apps for learning in my spare time (mostly just libsodium, but some golang libs). And I really want to try and implement some cryptographic ciphers such as ChaCha20, for purely learning purposes. Yes I know that I shouldn't roll my own crypto, but it wont be encrypting really anything other than the test vectors. I have been looking at the rfcs for it, but I wonder if there are any other resources to help me learn and implement the cipher. Thanks so much for any help. submitted by /u/bananafiasco [link] [comments] |
No comments:
Post a Comment