
Ask HN: I’m writing an OTP encryption algorithm. Where should I ask for review? - alanh
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).<p>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.<p>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?
======
Tomte
"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.

~~~
plugnburn
Here 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
"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?

~~~
plugnburn
Have you ever read how /dev/random data are actually gathered and how do they
differ from /dev/ _u_ random?

~~~
Tomte
Nice try. ;-)

[http://www.2uo.de/myths-about-urandom/#computationally-
secur...](http://www.2uo.de/myths-about-urandom/#computationally-secure)

~~~
plugnburn
In fact, nothing prevents us to lay a custom layer of gathering the entropy
_over_ (u)random, so all the issues mentioned in that article can be easily
circumvented.

If I had a license and enough money to buy Gryada-3 module, I certainly
wouldn't look into any pure-software solutions.

------
plugnburn
I 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.

------
kbart
There'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.

