One of my pet projects, which I've implemented in a ton of languages now, is a Spritz-based encryption and hashing program. This post will go over the latest incarnation of the file format I've devised. Right now it's only implemented in the Go version, but I plan to bring the Java version to a compatible state today.
There are 6 parts to the file format:
The Initialization Vector
The Password Key Generation
If you encrypt multiple files with the same password, it is useful to also include some random addition to the encryption process. That way, the cipher stream is different every time despite your input being the same. These random extra bytes are called the "Initialization Vector" (IV).
Since the IV is random, I believe most programs store it unencrypted at the start of their file. Just in case having easy access to the IV is useful to some future attacker, I actually XOR my IV with a hash of the given password. To me, it's so easy, why not take the extra step? Now you aren't even sure you have the right IV unless you have the right password.
So, that's the first 4 bytes of my output... the 32-bit random IV, XOR'ed with the 32-bit Spritz hash of the password string.
Generally, a cipher needs a fixed-size block of bytes for its key. Spritz doesn't need that, so I could have just used the password bytes + the IV bytes for my key. However, a second useful feature of keygen is to eat up resources, to make brute force attacks on the password take longer. As a result, I generate a key by multiple 512-bit hashes of the password string and IV, as follows:
Take the 512-bit output (hash) of the password Loop 20,000 + (fourth byte of IV) times: Initialize a fresh Spritz cipher Absorb the IV Absorb the latest 512-bits of data Store 512-bits of output for the next iteration Increment the IV by 1 The key is the last 512-bits generated
A couple points of interest that I'm happy with:
The number of iterations is slightly random (based on one of the bytes of the random IV). The goal is to complicate any kind of automated attack on the keygen, since the IV itself is also encrypted in the file based on the password.
The IV portion is re-added (and incremented) on each iteration, just in case there is some kind of hash-of-hashes weakness in Spritz where repeatedly re-hashing data converges on a smaller-than-512-bit space somehow.
It's nice and self-contained, using Spritz itself for the hash means not needing a separate SHA256 or whatever for use in keygen
Now, 20,000 iterations might sound low, but at least on my machine, it takes about 0.4 seconds for each key. So, even if you pulled together something 10,000 times more powerful, you'd only test about 25,000 keys per second. A long password is going to be hard to crack at that rate. So, I think I'm ok there. The general slowness of Spritz pays off in this case.
At this point, usually an encryption scheme wants to check that the given password is correct. A common way to do this is to store a hash of the generated key. If the hash of the key you just generated is the same as the hashed key you stored off, then the password was probably right.
I chose a different route. During encryption, I write 4 random bytes, and their 4-byte hash. I write both of these into the file encryped by the key. So, during decryption, once I have a key to test, I decrypt the next 8 bytes. If the second 4 are a hash of the first 4, then the key is probably correct.
This way, I still get the same kind of assurance as the typical method, but the bytes I use to do it have no relation to the key itself. This removes any chance that the key check data leaks any information about the key. It's a paranoid kind of approach, but this is an encryption scheme after all!
Actually, I left out a step in the above description of the key check: between the 4 random bytes and their hash, I actually skip a number of cipher stream bytes equal to the value of the fourth random byte. This way, anyone hoping to use some kind of bias in the early cipher bytes against me is dealing with an incomplete stream with a random-sized hole in it, which was encrypting random data in the first place.
We've done all this work to generate a key, and check it, but we're only going to use it to decrypt 512 bits. Those 512 bits are the real key used to encrypt the payload.
Why do this? Why not just use the key we painstakingly generated in the above steps? Because this way, you can change the password without re-encrypting the whole payload. You just change out the fixed-length header and leave the rest of the file still intact, still encrypted by the same payload key.
The downside of this approach is that there are actually two ways to crack the file: crack the password, or guess the payload encryption key. However, in practice this isn't a problem because the encryption key is fully-random noise. The user-supplied password is almost certainly easier to crack, so this approach doesn't reduce security in any meaningful way.
So, at encryption time, random bytes are written with the keygen'ed key. At decryption time, the keygen'ed key is used to read those bytes back. A fresh spritz cipher stream is created from those bytes and used for the rest of the file.
Just in case there is a useful way to attack the early bytes of the cipher stream, I skip the first bytes of the stream and don't use them. The number I skip also leverages random data: it's 2048 + the fourth byte of the payload key. The goal with the random skips is to defy easy analysis: if the starting point of the cipher stream is dependent on a random number, it's that much harder to reason about.
(It's common now when using RC4 to skip the initial bytes, which are known to be weak. RC4 and Spritz are somewhat related so it makes sense to bake in this precaution, since it's cheap to do.)
Part of securely encrypting data is not leaking any meta information about the payload. I want to be able to give the file its original name upon decryption, but I don't want that reflected in the encypted file name. So, the first part of the encrypted payload is:
1 byte giving the length of the filename
This also has the advantage of delaying the start of the actual payload by an unknown number of bytes, in case the initial portion of the payload is of use to an attacker.
I use zlib to compress the payload prior to encryption, which helps in three ways: the payload is usually smaller, the contents have less structure, and it obscures the size of the original plaintext.
What I like about this scheme is that every byte in the file is encrypted by some method, and I've tried to leverage random amounts where possible to help complicate any analysis. It's possible I could make some improvements to the keygen, and if so, I should be able to upgrade existing files without re-encrypting the payload.
The one feature that might be nice, which I didn't tackle, is random access into the payload. To do this, I'd need to operate in some form of counter (CTR) mode, so I could configure a cipher stream for region of the file in close to O(1) time. The complexity didn't seem to be worth it, for my needs.
It's been fun playing around with this, and I've learned a lot about encryption schemes and modes of operation in the process.
dededos
prguitarman
romaincrisis
gummygunk
discoholicmusic
stormborns
dailybridgerton
theartofmadeline