diff options
author | tomsmeding <tom.smeding@gmail.com> | 2017-05-04 22:30:55 +0200 |
---|---|---|
committer | tomsmeding <tom.smeding@gmail.com> | 2017-05-04 22:30:55 +0200 |
commit | 907fb164451bc65991051c35a616aa05db666846 (patch) | |
tree | 239ef5feeb007b14b305f2269ce7284768cbc1a3 | |
parent | f19210d6696efe118c5bb7906cdedc61bde9ff7c (diff) |
-rw-r--r-- | README.md | 2 |
1 files changed, 1 insertions, 1 deletions
@@ -5,4 +5,4 @@ Don't use this for actual crypto please. The code is probably buggy, the random 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. +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](https://doi.org/10.6028/NIST.FIPS.197)). However, it should work fine for normal sizes of data. |