aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authortomsmeding <tom.smeding@gmail.com>2017-05-04 22:30:55 +0200
committertomsmeding <tom.smeding@gmail.com>2017-05-04 22:30:55 +0200
commit907fb164451bc65991051c35a616aa05db666846 (patch)
tree239ef5feeb007b14b305f2269ce7284768cbc1a3
parentf19210d6696efe118c5bb7906cdedc61bde9ff7c (diff)
Fix AES spec link in READMEHEADmaster
-rw-r--r--README.md2
1 files changed, 1 insertions, 1 deletions
diff --git a/README.md b/README.md
index d5a6b34..db84eb5 100644
--- a/README.md
+++ b/README.md
@@ -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.