From 044cfbea266c6cea8beebd800e569efa8d28ae7e Mon Sep 17 00:00:00 2001 From: bleichen Date: Thu, 21 Nov 2019 03:13:47 -0800 Subject: [PATCH] Documentation NOKEYCHECK=True PiperOrigin-RevId: 281712273 GitOrigin-RevId: de1b278ef6898c9762f063ab2a08423fed033c4c --- doc/bib.md | 13 +++++++++---- doc/formats.md | 22 ++++++++++++++++------ 2 files changed, 25 insertions(+), 10 deletions(-) diff --git a/doc/bib.md b/doc/bib.md index 2f678af..5b01c04 100644 --- a/doc/bib.md +++ b/doc/bib.md @@ -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} diff --git a/doc/formats.md b/doc/formats.md index f92b624..09034fb 100644 --- a/doc/formats.md +++ b/doc/formats.md @@ -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.