n0p513d - 2015-04-09

otpcrypt uses a 24 byte file header on both the random pad file and the encrypted message files. The first 4 bytes can be used as a magic number for file type identification, the next four is a random serial number which is used to check that the decryption end is using the correct pad file. The remaining fields are used to keep track of messages and as a way of allowing for missing messages without messing up the pad file.

If a message is detected as missing, the program will prompt user and offer a chance to back out and try to locate the message, or carry on and loose the ability to decrypt the missing message.

At encryption time and decryption time, the pad file has the relevant section removed and the ability to decrypt that message again is gone.

A large one time pad file can be created in a few seconds (100Meg OTP file takes around 6.5 seconds on my PC). This amount of random data will encrypt the same amount of text and will provide a great deal of secure communication before Bob and Alice need to physically meet and exchange one time pad files again.

Random data for the one time pad file is obtained from /dev/urandom. If you have concerns regarding this you might want to visit http://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key.

Security of this pad file is key! It should be created, for example, on a USB key and physically handed to the person you want to communicate with. If anyone has chance to intercept and copy this pad file, all future communications using this file will be easily decrypted.

This project is a coding exercise for me, and I am a very inexperienced coder so it probably has a few bugs :-) I would appreciate any feedback, good or bad and preferably constructive.

Enjoy, and I hope this is of some use to anyone who values privacy.