A silly little one time pad exercise, using the MicaliSchnorr CSPRBG as given by Algorithm 5.37 in "Handbook of Applied Cryptography" by Menezes et al.

The gmp library (https://gmplib.org) is required.

Run: gcc -o encrypt.exe encrypt.c -lgmp gcc -o decrypt.exe decrypt.c -lgmp

Create a file named "msg.in", in the same directory as the 2 executables.

Run: encrypt.exe and the contents of "msg.in" is encrypted (based on the contents of "next_seed.txt" and "primes.in". The encrypted version of "msg.in" is then written to msg.enc.

Run: decrypt.exe and the encrypted "msg.enc" is decrypted into "msg.dec", where "msg.dec" is identical to "msg.in".

Decryption requires only that the same "primes.in" as was used to encrypt the message is available.

Security relies on "primes.in" being unavailable to potential attackers. Even if an attacker has encrypt.exe and/or decrypt.exe and/or the seed that was used at his disposal, it is useless without the information that is provided by "primes.in".

A suitable "primes.in" can be generated by running genprime.exe. (See the comments in genprime.c) There is, however, already a "primes.in" provided in this repo, for the purposes of demonstration. The fist line of this "primes.in" demo file is "32" - which indicates that the 2 values that follow are being expressed as base 32 values.

The "next_seed.txt" file needs to be found by "encrypt.exe", but "decrypt.exe" does not need it. The "next_seed.txt" file contains a seed value that is continually auto-incremented whenever "encrypt.exe" is run, thus ensuring that the same one-time pad is never reused.

And there's a perl test script (test.pl) which can be run to test that the encrypted file does, indeed, decrypt back to the original file (which was autogenerated pseudo-randomly by test.pl).