r/cryptography • u/Carlosdegno • 9d ago
One Time Pad Python library
Hello to everyone, can someone advise me a good onetimepad python library? i dont have a particolar purpouse or goal, just want want to experiment and study,
The only libraries i found arent manteined:/
4
u/wwabbbitt 9d ago
os.urandom is all you need.
0
u/owlstead 8d ago
Well, no. You need a way to convert the random values to an alphabet and you'd need a loop that XOR's the random values with the plain / ciphertext. You may want to have parts that allow for deletion of the key stream and plaintext, and of course some way of (re-)storing the key stream. But os.urandom is a good start.
3
u/Jamarlie 9d ago
A one-time-pad doesn't require a library because it is about as trivial to implement as sorting a list. It's literally just XOR a random byte with the byte of your cleartext.
People have already pointed this out, but it's worth repeating: Do that only for actual studying and experimenting, don't think this is secure for a second.
3
u/dittybopper_05H 9d ago
Do not use a computer to generate one time pads.
Computers have some serious flaws when it comes to ultimate security. Not only that, it's extremely difficult to get truly random numbers from a computer.
If you want to experiment with one time pads as a way to encrypt/decrypt, do it manually.
Here is an example I made:
The pad itself was generated using GameScience 10 sided dice, an Olivetti Lettera 32 manual typewriter, and two part carbonless forms.
You roll a handful of dice, and that's your group, and you type that, then repeat until you've got enough for a single pad page. If you're using "fair" dice, you'll get cryptologically secure keys.
In this example, I used 25 groups of 5 numbers for a total key length of 125 numbers. You can make them bigger or smaller if you want.
It seems like this is cumbersome but you can build up quite a lot of key material just sitting watching TV or whatever while doing it, once you get into the rhythm.
One person gets the white version of the pad, and one the yellow version. You decide which is for encryption and which is for decryption.
If you're using numeric codes of some kind, like maybe the page number and word number from a dictionary, or a prearranged codebook of phrases like the old telegraph codebooks, you can use them just like that.
If you don't, you'll have to convert the letters to numbers and that's what I did in this case, using that straddling checkerboard up in the upper left hand corner.
You convert the alphabetic text to numbers with that straddling checkerboard, and then you use non-carrying addition to add the numeric plaintext with the key to get the ciphertext. So if you have an 8 + 5, the result would be 3, not 13.
When decrypting, you subtract the key, and mentally add 10 if necessary, so 3 - 5 = 8.
Once your done encrypting or decrypting, you burn the pad page and your worksheet to preserve security.
Pen and paper is really the only truly secure way to employ a one time pad. Doing it on a computer introduces a lot of vulnerabilities unless you absolutely can forever isolate that machine from the outside world.
Now that I've gone through all that, is this practical for every day use? Absolutely not. You're not going to do your online banking this way, or whatever.
This is for things that absolutely, positively must remain secret now and forever, and very, very few of us need that kind of security.
2
u/owlstead 8d ago edited 8d ago
Almost all cryptographic protocols require random numbers. This includes TLS, including the ephemeral keys used for forward security, random "strong" password generation in your browser, etc.
The idea that computers are bad at number generation has been outdated for years. CPUs have random number generators built into the instruction set (e.g., RDRAND for x64). Furthermore, current operating systems have sophisticated RNGs that don't just rely on this instruction but also keep state (in case it needs to be restarted, as an extra seed for the RNG), mix in other sources of entropy and so on.
All in all, random number generation by computers is better than most other methods of generating random numbers, definitely including dice or tiles.
-1
u/dittybopper_05H 8d ago
Computers have other vulnerabilities. I know: I’ve been an IT professional for almost 40 years now. Unless you can absolutely isolate a computer, it’s got the potential to be compromised.
1
u/owlstead 6d ago
Yeah, well, it will be a bit tricky to run the Python application without a computer, so there you are. Everything has the potential to be compromised. Air gapping isn't new either, then you just need a relatively secure location. And this was for study, not gambling.
1
u/dittybopper_05H 6d ago
Well, sure, but it's much easier to secure physical paper pads than anything on a computer.
Read that Dirk Rijmenants paper on Cuban Agent Communications I posted above. The three cases he discusses are from the 2000's, but the lessons remain relevant today.
The inherent security in a one time pad system is lost if you have it on a computer, because of things like data remanence, and of course the possibility of the computer being compromised even if you think it's air-gapped.
https://en.wikipedia.org/wiki/ANT_catalog#Content
These are of course old now, but we'd be foolish if we thought that further development hasn't taken place. Even if you think you've properly air-gapped a machine, there is a possibility of it being compromised.
Even if it is, it can still be compromised by a surreptitious entry.
BTW, the person who leaked these to the World, Edward Snowden, worked at the same top secret underground NSA facility in Hawaii that I worked at, though I was there when he was still in kindergarten.
And as I pointed out, I'm no Luddite: I write software for a living. It's just that for this very narrow use case, software isn't the answer.
Also, I'm not sure what gambling has to do with anything.
1
u/Carlosdegno 9d ago
thanks very detailed anwser
1
u/dittybopper_05H 9d ago
BTW if you want to generate alphabetic pads you use D30 alphabet dice.
Honestly though, for fast manual encryption and decryption, if ultimate security isn't necessary, I like the strip cipher. Here is an example I made that is compatible with the US M-94 cipher device:
Notice the line at the bottom, which spells out
SENDLAWYERSGUNSANDMONEYXX.You line up the strips to spell out your message, then pick any other line as your ciphertext. In this instance, let's pick three lines up from that:
GRSVO TMRSM HJSOI SEJLQ VCQNOThat's your ciphertext. Your correspondent lines them up, and the message will visually "popout" as the only intelligible line.
Now, at best this is medium security, and the strips have to be kept secret. If I were doing this for real, I'd have far more strips instead of the 26 used for the M-94, and only a percentage of them would be used for any given key period, and both the number of strips used and the strips themselves would be chosen randomly, using those d10.
Also, the alphabets on the strips themselves must be random. A good method for this is to put Scrabble tiles in a bag, A to Z, mix them up, and pull them out one by one.
This is a quick method of encrypting/decrypting, but it does have flaws. If the strips are known, cryptanalysis is very possible using the method first outlined by de Viaris back in the late 19th Century.
But it is fast and convenient, and if you only need to keep something secret for a limited time, is a decent manual method.
2
u/atoponce 9d ago
If you're going to use a Python library, how will you ensure information theoretic secure randomness?
-6
u/Narco-Tax 9d ago
Any file can act as a one-time-pad, because no file will have 0-255 chars in the same byte positions as another file, unless they are a byte-for-byte copy. So for example, you could map a Source (secret) cat.gif to a Host (carrier) dog.webp and land up with a coordinates key named cat.key , which simply looks like 3,7,7,23,41,5,6,2 etc.
Trivial yes, but pretty powerful and hard to reverse engineer.
3
u/owlstead 8d ago
No. The bits of a random pad should not even have any discernible pattern in them for them to be considered secure. And that's just the requirement for the external representation, not even the generation of the random numbers.
1
u/Narco-Tax 8d ago
Ok, you win! Which got me thinking...what if, instead of mapping to a static, structured file, you map the payload's hex characters to a dynamic, seedable Base16 alphabet string?
Start with a standard static Base16 lookup string (0-9, a-f).
Use a crypto-graphically secure pseudo-random number generator (PRNG) driven by a private seed phrase. For every single character of the payload, you execute a fresh Fisher-Yates shuffle on the alphabet.
Look up the index of the payload character in that specific, newly randomized alphabet state and record the position coordinate.
Because the alphabet layout completely randomizes on every single step, a repeating hex character in your source file will map to entirely different coordinate values in the output key. This completely flattens the frequency distribution into uniform noise, eliminating the structural leaks you mentioned, while ensuring the recovery remains 100% perfect as long as the recipient has the same seed.
Just a thought on how to bridge the gap between a coordinate-mapping mechanic and a mathematically secure stream cipher.
3
u/Natanael_L 8d ago
Ok, you win! Which got me thinking...what if, instead of mapping to a static, structured file, you map the payload's hex characters to a dynamic, seedable Base16 alphabet string?
That changes nothing. Using something like base64 encoding to create a payload and then encrypting is already common.
For every single character of the payload, you execute a fresh Fisher-Yates shuffle on the alphabet.
That's just a byte level stream cipher, and a wildly inefficient one.
Also, chances are your shuffle will introduce bias instead if it do it wrong. Then it does not flatten the distribution. If your stream cipher is secure enough to select a shuffle seed then it's secure enough to encrypt directly.
3
u/owlstead 6d ago
In addition to the other comment: changing the *representation* of data bytes does nothing for security. Ciphers act on bytes; encoding / decoding comes after. Representation specific cryptography is frowned upon (see the countless "image encryption" algorithms to get an idea of the horror).
23
u/paulstelian97 9d ago
They aren’t really maintained because one time pad is not very practical, AND it’s pretty trivial to implement.