diff options
author | tomsmeding <tom.smeding@gmail.com> | 2016-10-08 09:49:38 +0200 |
---|---|---|
committer | tomsmeding <tom.smeding@gmail.com> | 2016-10-08 09:49:38 +0200 |
commit | 2fe3a5f06bf4423fbb881238b30f6f592b5c0127 (patch) | |
tree | 1a13b8b194f4c5be6f0af0ffcce58c67f8132316 | |
parent | 70a7537584889cf612ddea83eb65fd42818f6e5e (diff) |
Add readme
-rw-r--r-- | README.md | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/README.md b/README.md new file mode 100644 index 0000000..d5a6b34 --- /dev/null +++ b/README.md @@ -0,0 +1,8 @@ +Unsafe C++ Crypto Toolkit +========================= + +Don't use this for actual crypto please. The code is probably buggy, the random generators predictable, and the encryption/decryption functions vulnerable to every timing attack you can imagine. + +Okay, that's the sad version. The happy version: this is a working suite that does RSA and AES, with no dependencies at all (except the C++ standard library). The code makes some assumptions about the integer sizes of the platform, but that should be checked with `static_assert`'s. Above all, it's interesting code, and illustrates how hard it *actually* is (or isn't) to implement an established crypto algorithm. + +Attention wasn't much paid to performance. The bigint implementation probably could've been way faster, and the same holds for AES (I don't use Intel's obscure processor instructions that are supposed to make it faster, nor am I using the lookup tables; the code is just a straight implementation of the [spec](http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf)). However, it should work fine for normal sizes of data. |