Will likely redo this from scratch at some point in the near future, this is too rough of a prototype and should be cast aside now the core aspects have figured out instead of trying to refine it.
Lockout is a prototype which is designed to place a barrier between the user and data which they have encrypted by scrambling a predetermined portion of the key.
The internet is addictive (wow, right?). Deleting a user account can be a pretty major step to take, sacrificing all of whatever investment you have put into it. While many websites offer a softer deactivation option for people unwilling to do that, this is often as easy to reactivate as regularly logging in, which serves to make it incredibly easy to get drawn back in again.
To delete ones account, there is a 14 day grace period where it is effectively just deactivated. That's a pretty long timespan to either (a) change your mind and get back into it or (b) decide that deletion is too big of a step and opt to deactivate the profile instead. When deactivating a profile, the barrier to returning is practically nonexistant, just enter your login credentials and resume as before. Maybe there's some slight social shame if you make a big deal out of quitting.
By changing your password to one generated via this program (and, in the case of facebook, removing the easier account recovery options), you can put a significant time barrier between deciding to access your account and actually being able to.
The user provides the following inputs
- plaintext (PT)
- user password (PW)
- decryption strength (DS)
- a salt word (optional) (S)
- PW is passed through a hash algorithm
- the first X bits (currently 128) of h(PW) are subsequently passed into a key generator along with DS
- The key generator maintains the first DS of h(PW) and replaces the remaining 128 - DS bit with randomised values to create the encryption key K *
- The plaintext is appended with either the optional S or PW if no S was given
- The plaintext is encrypted using K, all other inputted values are forgotten unless saved elsewhere
- //note: it currently maintains the first DS/8
bytesand limits the next byte to a figure which ensures the brute force algorithm will resolve its value within the desired level of complexity. e.g. An argument of 127 will keep the first remaining 15 bytes of a 16 byte (or 128 bit) key as is, the final byte will be limited to a value of range 2^1 values. I do plan on eventually writing up all of these portions using bitwise operators to get a bit better with them, but I don't want to wreck my head with that for now.
The user provides:
- ciphtertext (CT)
- user password (PW)
- salt word (optional) (S)
An initial test key is built using h(PW) A recursive function attempts to decrypt the ciphertext using all possible key combinations, beginning by changing the final bit and working its way back. Following each attempt, a check is made to see if the appended value from step 4 is present, in which case it has successfully decrypted the data.
If the user has retained the value of DS when decrypting, they should know the maximum number of attempts needed and therefore also be able to eventually tell whether they attempt was unsuccessful.
Currently at the most basic acceptable stage, the next steps for this project are:
- A process to read in and write to files
- Timing tests added to debugging to remove significant inefficiencies (only significant ones, it's beyond my scope to make this run perfectly)
- Formal command line argument schema and some general security tests.
- Separate password prompt implementation unless specified in command
- Simple command-line user interface
- a client side Javascript implementaion (likely using a faster algorithm)
- self-coded implementation of AES
- this actually being as useful as I hope
To run the current, very basic, test implementation: Compile with
gcc -o tester test.c aes.c sha256.c lockout.c
To run
./tester [password] [user inputted string argument] [decryption difficulty]
- Due to some lazy testing, the password currently needs to be exactly 8 characters
- User inputted string is currently set to a limit of 32 bytes, just change the TEXTSIZE constant to make it larger. Will make this flexible at some point.
- decryption difficulty currently specifies how many entries of the key are NOT to be randomised (i.e. 128 means all 128 bit are to remain as is). I recommend leaving this setting at a figure over 112 until you decide which outputs you wish to leave in.
For want of a better word... but yes(!), I'd love to hear some questions and feedback. Right now I'll just run through what I can think someone may ask. I'll just add content here as I think of it for now.
The primary reason is kokke's AES implementation uses them and I liked the consistency https://github.com/kokke/tiny-AES128-C A secondary reason is, as I opted to work around dealing directly with bit level changes and have no desire to make the system use more than an 8-bit character set, I found it pretty helpful as a reinforcement that I would dealing with a series of bytes rather than a string. This system uses my usage pretty liberally, treating them as unsigned char variables all over the shop without explicit casting.
This repo utilises other people's code in the following sources:
aes.candaes.huse TINY AES128 C by kokke from https://github.com/kokke/tiny-AES128-Csha256.candsha256.huse B-Con's implementations https://github.com/B-Con/crypto-algorithms If there are any issues with these inclusions, they will be replaced with alternatives shortly after I have been notified. I've made a point of not meddling with this code much.