Compare commits

..

13 Commits

3 changed files with 864 additions and 526 deletions

View File

@@ -1,6 +1,47 @@
# OTP Cipher - One Time Pad Implementation # OTP Cipher - One Time Pad Implementation
A secure one-time pad (OTP) cipher implementation in C with automatic versioning system.
## Introduction
A secure one-time pad (OTP) cipher implementation in C.
## Why One-Time Pads
Nostr and much of the web runs on public key cryptography. Public key cryptography is great, but it is vulnerable. Cryptographers know this, and they know what it takes to attack it, so what they do is just make the keys large enough such that the system is resistant to attack given computers as they are today.
There is one type of cryptography, however, that is invulnerable to any type of attack in our universe, and that is known as a one-time pad.
One-time pads rely directly on the laws of physics and what it means for a number to be truly random.
If you take your secret message and mix it with truly random numbers, and don't use those random numbers again, then that message is unbreakable by any computer, no matter how powerful, quantum or not, forever.
In fact, one-time pads are so powerful that if you have data encrypted by a one-time pad located in a distant galaxy, and that data is not kept anywhere else, then by destroying the pad used for encryption in your galaxy, the data is wiped from the universe and can never be recovered.
## Advantages and Limitations
### Limitations
1. The pad must be shared between the parties wanting to use it.
2. The pad must be as long or longer than what you want to encrypt, and it can't be used a second time.
### Modern Advantages
While in the past, pad length might have been a problem, readily available USB drives in the terabytes make size less of a problem for many uses.
We are also becoming very accustomed to YubiKey authenticators in the USB ports of our computers. A small USB drive in our devices can now easily contain a key of greater length than all the text messages we would expect to send over a lifetime.
### Multi-Device Coordination
One of the problems to address is the fact that to use an OTP across several devices means that they have to coordinate to know when they are encrypting new plaintext and where to start in the key. Reusing the same section of the pad, while not necessarily fatal, degrades the encryption from its status as "Information Theoretically Secure".
To address this problem, we can use Nostr to share among devices the place in the pad that was last left off.
### Additional Benefits
One-time pads can be trivially encrypted and decrypted using pencil and paper, making them accessible even without electronic devices.
## Features ## Features
@@ -13,15 +54,6 @@ A secure one-time pad (OTP) cipher implementation in C with automatic versioning
- **Multiple Build Options**: Standard and static linking builds - **Multiple Build Options**: Standard and static linking builds
- **Cross-Platform**: Works on Linux and other UNIX-like systems - **Cross-Platform**: Works on Linux and other UNIX-like systems
## Version Information
This project uses an automatic versioning system that:
- Automatically increments the patch version on each build
- Embeds build timestamp, git commit hash, and branch information
- Creates git tags for version tracking
- Generates version header files with detailed build metadata
Current version can be viewed with: `./otp --help` or by running the interactive mode.
## Building ## Building
@@ -31,7 +63,7 @@ Current version can be viewed with: `./otp --help` or by running the interactive
- Git (for version tracking) - Git (for version tracking)
- Make - Make
**Note: OpenSSL is no longer required! This implementation is now completely self-contained.**
### Build Commands ### Build Commands

19
TODO.md Normal file
View File

@@ -0,0 +1,19 @@
# TODO
## Change technique for adding keyboard entropy.
## There is the problem of the location of the pad revealing metadata about how many messages have been sent in the past, or at least the size of the messsages.
One solution could be to start the pad at a random location, and then wrap around, so an attacker could never tell the size of the past text sent. This helps. But then you have to store the start location, which you could do within the header of the pad along with the pad?
Or, better yet, assume the offset is a very large size, and use the pad itself to encrypt the offset.
## Take a look at how the file header is being handled.
## Setup for multiple USB drives

1317
otp.c

File diff suppressed because it is too large Load Diff