Wrong Type of Encryption Algorithm

[marcoonroad]

It's quite wrong to use ARC4 / Stream Cipher encryption algorithms here. I really don't remember why I had such idea in the first place. Stream ciphers are only good if the following conditions are meet:

• The data has a variable size (imagine streams of video or telephone calls).
• The keys to encrypt are never reused again.

In our current state of affairs, we're doing the opposite of that. Really. And it's really insecure by doing that, so. Really. Our private keys have a fixed-length, first and foremost. We're quite wrong here, and it's annoying for any expert information security engineer to see that. By second, the keys to encrypt and decrypt private keys can be used and reused again, indefinitely, 'cause it's the responsibility of the caller / client of our library to define that. Again, we're quite wrong and this can render the whole Post-Quantum security of this library as flawed even on Classical Machines.

Therefore, I should figure out Block Cipher algorithms to use here instead. By preference, strong ones.

[marcoonroad]

The most known good encryption algorithm is Blowfish, but neither the author recommends it anymore. Instead, he recommends Twofish and forward. Twofish is slower than AES, in which is slower than Blowfish, but I should not care about performance, 'cause the importing and exporting of private keys is not an often operation in the same sense of signing and verification. There's no Twofish implementation for OCaml, only Blowfish. Therefore, I must implement Twofish by hand in OCaml or link C bindings here.

[marcoonroad]

I've changed my mind a bit by now. I'm using the already provided AES encryption in the Nocrypto library. There's no problem in using ECB mode of operation, 'cause our data (the private keys) are quite random, and thus, no pattern is leaked by the deterministic encryption nature of the algorithm. If our encrypted data were sensible and non-random, for instance, this picture of me, the encrypted message (a.k.a cipher text) would leak some patterns, such as my face's traces, and therefore, privacy and confidentiality are broken. In such case, the CTR and CBC modes of operations are recommended.

[marcoonroad]

(It doesn't mean / imply that future plans for Twofish doesn't exist.)

[marcoonroad]

Update:
I must use a Password-based Key Derivation algorithm. Currently, the encryption uses a sole SHA256 hash (derived from password) as encryption key. It's unsafe. Quite unsafe. Nowadays, there are CPU instructions, GPUs, FPGAs and even ASICs dedicated to SHA256 hashing. It's not much hard to perform brute-force / dictionary attacks on that, and some analysis beforehand guessing good password candidates turns it even more easy.

The existing Password-based Key Derivation algorithms are (from the most weak to the most strong):

• bcrypt
• pbkdf2
• scrypt
• argon2

Such Password-based Key Derivation Algorithms perform intensive tasks to hardening and slow automated brute-force attacks.

Another possible solution is to use a deterministic Proof-of-Work (based on the given password) to derive an encryption and decryption key. The user/client could set the difficulty during the encryption/decryption process, so it would take a random but long amount of time to backup and restore private keys, thus rendering brute-force attacks infeasible.

[marcoonroad]

Proofs-of-Work are often RAM-memory-friendly, so attacks made by ASICs decrease the hardening embedded as a Key Derivation Function here. I should drop such "hacking" / workaround and look forward the Argon2 password-based key derivation function anyways.

[marcoonroad]

BUMP:

There's some folks who don't trust AES. 🙃
(Perhaps neither me...) 🤔
Therefore I should look forward another Encryption algorithm.

[marcoonroad]

I've changed my mind a bit by now. I'm using the
already provided AES encryption in the Nocrypto
library. There's no problem in using ECB mode of
operation, 'cause our data (the private keys) are
quite random, and thus, no pattern is leaked by
the deterministic encryption nature of the
algorithm. If our encrypted data were sensible
and non-random, for instance, this picture of me,
the encrypted message (a.k.a cipher text) would
leak some patterns, such as my face's traces, and
therefore, privacy and confidentiality are broken.
In such case, the CTR and CBC modes of
operations are recommended.

Nevermind, using AES CBC nevertheless.