5 ms·
Ask HN: I’m writing an OTP encryption algorithm. Where should I ask for review?
I have always heard and respected the advice: Never roll your own crypto! Well, I’m planning to roll my own crypto. This might be less stupid than it sounds as it ’s going to be a glorified one-time pad, and one-time pads have the delightful properties of being incredibly simple to understand and also completely unbreakable (if used properly).
It’s the parenthetical condition above that worries me, and I’d be grateful for some peer review after I finish the first version of my algorithm.
I don’t hang out in crypto circles, so I thought I would ask HN: Do you have suggestions for communities, persons or entities who might be interested in reviewing my algorithm and implementation?
- kbart 11y agoThere's an active cryptography mailing -- http://www.metzdowd.com/mailman/listinfo/cryptography http://www.metzdowd.com/mailman/listinfo/cryptography. You might try there, but I wouldn't get too excited as you may know, cryptography professionals look suspiciously to the amateurs rolling their own crypto. My own warning: algorithm itself is not the hardest part, a bug free, safe from side-attacks implementation is.
- Tomte 11y ago"This might be less stupid than it sounds" No, it is even more stupid than it sounds, because "as it’s going to be a glorified one-time pad" One-time pads are impractical. You need a key that's as long as your message. Pre-shared. You need "information-theoretic security" of your random numbers (that's extraordinary!). You must never ever re-use the key. Exactly 100% of One-time pads that people code are simply badly done stream ciphers, not One-time pads.
- oniony 11y agoThe stupidity of an exercise should be measured upon its motivations. If OP is doing this for entertainment or for their own education then it is far from stupid.
- plugnburn 11y agoHere in Ukraine, we have a nice saying: "Don't rush into the hell before your father". I.e. don't make any prejudiced conclusions before you get any single answer. I am too in a doubt that the OP sees the diference between OTP and SSC, but he has to answer himself. Cryptography was my primary speciality in the university, and I know for sure that "information-theoretic security", i.e. degree of randomness, of a bit sequence, isn't a rocket science. For it to exist, the sequence must pass a row of tests. It's not so hard to achieve. Finding the actual entropy source is much harder. Without a dedicated chipset (have you ever heard of Gryada-3 (Гряда-3, roughly translated as Ridge-3) RNG module? Probably not, it's a Ukrainian invention), human interaction (mouse movement etc) or using external sensors (temperature deviations, for example) the only entropy source I can think of is RDTSC timestamp gathering. For us mere mortals, even /dev/random will do. But the most interesting question for me is how the hell (which you shouldn't rush into before your father) the OP is going to distribute and sync the random pile of data. That alone is quite a hard problem, especially if the pile is distributed between more than two users. So let's be patient and wait for the answers.
- Tomte 11y ago"For it to exist, the sequence must pass a row of tests." Sorry, that's laughable. "even /dev/random will do" It's just not OTP anymore, but who cares?
- arsenide 11y agoWhy is it laughable? I'm not disagreeing with you: I am rather curious.
- Tomte 11y agoBecause information theoretic security is a property of a randomness source, not its output data. And it has a stringent definition. The idea that "I'm throwing the output of some randomness source at Diehard, and if Diehard says it's good then the source provides information theoretically secure random numbers" is a category error at best.
- plugnburn 11y agoForgot to answer this: > One-time pads are impractical. You need a key that's as long as your message. Pre-shared. Need in a key as long as your message (pre-shared) doesn't mean that OTP is impractical. Let's imagine a conversation between two users that exchange tweet-sized messages in Latin-1 encoding (i.e. each plain message weighs no more than 140 bytes). Let's consider we've produced exactly 4 GiB of random key data and distributed it between the two users (on a pendrive or somehow else). When the message is received, its encrypted length is the same as the raw length, so we just move the key pointer for the message length on each send and reception. So how many 140-byte messages can be sent with 4 GiB of key data? Math.floor(4 * 1024 * 1024 * 1024 / 140) = 30678337. So, 4 GiB of pre-shared key data allows us to send over thirty millions of tweet-sized messages for both sides. How in the world is this impractical? Especially at our days when a 16 GiB file is a norm. And yes, pre-sharing these key data can involve a simple SSC, BSC etc. It might be hard for an attacker to figure out when to stop when he constantly gets a random garbage out of the same-looking random garbage.
- rnovak 11y ago> Let's consider we've produced exactly 4 GiB of random key data and distributed it between the two users if you have a method of securely distributing 4gb of key, why on earth wouldn't you use that to transmit the message itself? That's 100% impractical
- plugnburn 11y agoBecause that method doesn't imply the key distribution channel will be available 100% of the time. In fact, it implies the opposite: one-time transmission. For the next 4 GiB, it would be wiser to switch the channel. Between these two occasions, we have plenty of time.
- rnovak 11y agoIt doesn't matter. In order for OTP to work, you first have to invent secure communication. It puts the horse before the carriage. Oh, and now you have to maintain perfect secrecy/privacy of a 4gb file. Solved one problem (theoretically), and now you have a multitude of practical issues. So again, OTP is impractical.
- plugnburn 11y agoI don't have time for exactly reviewing your algo and implementation, but I'd like to be sure: What's your algo supposed to do? One-time-pad, you know, is just a system of distribution and usage synchronization of truly-random key data. The key data itself cannot be generated with any algorithm. If they are, it's not a one-time pad, it's a stream symmetric cipher. So, if you are going to really write an OTP implementation, I have to ask the first question one more time: what is your algo supposed to do? The second question: how do you create a random keystream in order for it to be truly random, not pseudorandom? And the third question: how are you going to distribute and synchronize that random pile? Answers to these three questions would certainly increase the interest in reviewing your algorithm and implementation. Thanks in advance.