Documentation
NOKEYCHECK=True PiperOrigin-RevId: 281712273 GitOrigin-RevId: de1b278ef6898c9762f063ab2a08423fed033c4c
This commit is contained in:
+9
-4
@@ -96,9 +96,14 @@ https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/
|
||||
|
||||
### HowSma99 {#HowSma99}
|
||||
N.A. Howgrave-Graham, N.P. Smart,
|
||||
“Lattice Attacks on Digital Signature Schemes”
|
||||
"Lattice Attacks on Digital Signature Schemes"
|
||||
http://www.hpl.hp.com/techreports/1999/HPL-1999-90.pdf
|
||||
|
||||
### Krawczyk10 {#Krawczyk10}
|
||||
H. Krawczyk,
|
||||
"Cryptographic extraction and key derivation: the HKDF scheme",
|
||||
https://eprint.iacr.org/2010/264.pdf
|
||||
|
||||
### Nguyen04 {#Nguyen04}
|
||||
P. Nguyen,
|
||||
“Can we trust cryptographic software? Cryptographic flaws in Gnu privacy guard 1.2.3”,
|
||||
@@ -176,11 +181,11 @@ http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf
|
||||
### NIST-SP800-57 {#NIST-SP800-57}
|
||||
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
|
||||
|
||||
### NIST SP800-131A {#NIST-SP800-131A}
|
||||
### NIST SP800-131A Revision 2 {#NIST-SP800-131A}
|
||||
Transitioning the Use of Cryptographic Algorithms and Key Lengths
|
||||
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
|
||||
Some notable changes: Keys with less than 112 bit security are now disallowed.
|
||||
EdDSA will be added with FIPS 186-5. TDES is disallowed after 2023.
|
||||
Some notable changes in revision 2: Keys with less than 112 bit security are now
|
||||
disallowed. EdDSA will be added with FIPS 186-5. TDES is disallowed after 2023.
|
||||
RSA PKCS 1 v.1.5 for encryption is disallowed after 2023.
|
||||
|
||||
### EnisaKeySize14 {#EnisaKeySize14}
|
||||
|
||||
+16
-6
@@ -7,15 +7,25 @@
|
||||
This document contains a general overview over the formats used and conventions
|
||||
used for all test test vectors. Test types have specific formats, which are
|
||||
defined in [types.md](types.md). The test files and the tests intended with
|
||||
these test files are described in [files.md](files.md).
|
||||
these test files are described in [files.md](files.md). In a number of cases
|
||||
there are distinct tests for distinct output formats. E.g. DSA and ECDSA
|
||||
signatures both have separate test vector files for ASN encoded signatures and
|
||||
P1363 encoded signatures.
|
||||
|
||||
## JSON schemas
|
||||
|
||||
All test vector files contain valid JSON. The root structure contains the field
|
||||
"schema", which is the file name of the JSON schema for this file. The JSON
|
||||
schemas are in the directory `wycheproof/schemas/`. The JSON schemas are still
|
||||
in an experimental state. Being unfamiliar with JSON schemas it is often not
|
||||
clear which syntax is well supported. Hence some changes in the schemas should
|
||||
be expected in the future.
|
||||
|
||||
However, the plan is that major changes in the format of a test vector file
|
||||
will be reflected by a changed JSON schema file.
|
||||
|
||||
## General conventions
|
||||
|
||||
* All files contain valid JSON. The root structure contains the field
|
||||
"schema", which is the file name of the JSON schema for this file. The JSON
|
||||
schemas are in the directory `wycheproof/schemas/`. Changes in the format of
|
||||
a test vector file that break compatibility will be reflected by a changed
|
||||
JSON schema file.
|
||||
* The data included in the header of the test vector file and the test groups
|
||||
are always well formatted. Only inputs contained in the individual tests may
|
||||
be malformed.
|
||||
|
||||
Reference in New Issue
Block a user