17

I'm one of the authors of Gimli. TL;DR: Test vectors provided by the paper are indeed wrong. We had a error when we generated the paper and the test vectors have not been updated with respect to the last iteration of Gimli (in development stages). Also one of the test vectors had a double space at some place. This has been corrected and will be updated in ...


14

Here are five test vectors for secp256k1, which I just generated with my own code. My code is a generic implementation of elliptic curves; it has been tested for many curves for which test vectors were available (in particular the NIST curves) so I tend to believe that it is correct. Each test vector is a value $m$ (chosen randomly modulo the curve order $n$)...


13

For any of the algorithms approved by NIST you can usually find the test vectors in the Cryptographic Algorithm Validation Program (CAVP) - for instance for 3DES in appendix B and AES in appendix C. Test vectors are usually found in one of the appendixes or later sections of the documents. For any others you should first look to the standard documents, ...


10

There are in the RFC : http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#section-7 The following blocks contain test vectors for ChaCha20. The first line contains the 256-bit key, the second the 64-bit nonce and the last line contains a prefix of the resulting ChaCha20 key-stream. KEY: ...


10

can we say that it is fully conforming to the specification, and must have been implemented correctly? No. Is it possible to backdoor a cipher (or hash function, I suppose) in such a way that it still appears to be correct and is compatible with different implementations of the same cipher? Certainly. Say I have an function AES(k,m)=c where variables k ...


7

There are RSA keys pairs in the validation suite for the RSA part of FIPS 186-4 (see second part of this answer for details). Because "encrypt/decrypt by RSA method" is not well-defined (for lack of indication of the padding method), there's no way to tell which Known Answer Test vectors for it fit the question's need. Also, only the decryption code can be ...


5

You'll find the test vector in a draft "Test Vectors for the Stream Cipher ChaCha draft-strombergson-chacha-test-vectors-00" available at the following link: http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors-00 The document links a github repo where you can find all the vectors https://github.com/secworks/chacha_testvectors/ Another ...


5

Here are some test vectors for secp256k1 in the spirit of the test vectors you referenced: Curve: secp256k1 ------------- k = 1 x = 79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 y = 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8 k = 2 x = C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5 y = ...


5

<------------- key -------------> <-- plaintext -> <- ciphertext -> E62CABB93D1F3BDC 524FDF91A279C297 DD16B3D004069AB3 8ADDBD2290E565CE B619F870574A9E80 DAE6AB34C22CD626 058B92A4B28FB4EB A53DDC6B3098008F 6132C42C3E5E94EF 7A5152BF19AB739D 91993307EFBFB13C D13105386083E517 0245EAFE62DF92BF E319C29E9E2C3EA1 58BAA732CF5DBD77 EF37441D1FE7B73A ...


5

This hastily written implementation of HKDF in C# agrees with the RFC test vectors: private const int SHA1 = 1; private const int SHA256 = 2; private static HMAC NewHMAC(int h, byte[] key) { switch (h) { case SHA1: return new HMACSHA1(key); case SHA256: return new ...


5

All of your questions are answered in the Validation System documents that are linked to by the algorithm test pages. In this case, look at http://csrc.nist.gov/groups/STM/cavp/documents/shs/SHAVS.pdf For this case, the message length is expressed in bits not bytes. The fact that the message is also encoded as value of 00 should be ignored in the test ...


5

As usual, government departments simply repeat their existing rules. So they incorporated the Monte Carlo tests from earlier test documents, this time from 1980. If you follow the dusty trail from Maarten's link, you eventually arrive at NBS Special Publication 500-20, Validating the Correctness of Hardware Implementations of the NBS Data Encryption ...


4

One common pitfall when implementing HMAC(key, data) is mishandling the case when key is longer than the underlying hash block. In your case salt is 80 octets, which is longer that SHA-256 "block" (64 octets) so the salt have to be run through SHA-256 before being XOR'ed with i_padin the HMAC. Without seeing any actual code, and provided that the test ...


4

The answer is "no", in two ways. First, the implementation of the algorithm could make use of side channels to leak data. The SSL timing attack permits an attacker who can execute multiple encryptions to "tease out" timing information that reveals bits of the key material. The original attack was based on the widely used OpenSSL implementation. Simply ...


4

It looks like there's an error in the test vector. The text of Appendix B.1 states: P1 = “The quic” = 5468652071756663 ... which is incorrect. The hex encoding of The quic is actually 5468652071756963 (note the transposition of the i/69 to an f/66 in the encoding. e.g. encrypting the test vector as intended: $ echo -n 'The quick brown fox jump' | ...


4

RC4 is some kind of pseudo random number generator. You input a key (seed) and now can get a stream of pseudo random numbers. The values here are this numbers, always a byte at a time. Unlike a block cipher, you don't have a plaintext. You use this key stream to add it to the plaintext to get the ciphertext. "Adding" can be done with XOR, because that's ...


4

OK, so I quickly found out that there is a test in Bouncy Castle called: org.bouncycastle.crypto.test.ECTest.testECDSASecP224k1sha256() which tests exactly what you are trying to do (with a message the same size of a SHA-256 hash). So I decided to create a new test that duplicates this test, but for SecP256k1 and SHA-256. I've generated the following ...


4

I think the flash implementation is wrong: (using Linux, OS X terminal etc.) not true, see below echo 328831e0435a3137f6309807a88da234 | xxd -r -p > plain.dat openssl enc -e -aes-128-ecb -iv 00 -K 2b28ab097eaef7cf15d2154f16a6883c -in plain.dat -out plain.dat.out -nopad yields hd plain.dat.out 00000000 57 16 aa fa 2c ...


4

Might I suggest the "DES cipher internals in Excel" page by Nayuki? Because everything's in Excel, all the internal values are openly displayed.


4

This would not be recommended in most cases. Note that AES-GCM fails terribly if an IV repeats. In a 64-bit block cipher, if you want the probability of such a failure to be below $2^{-32}$, then you would be very limited in the number of messages you can encrypt. If you can guarantee a unique IV each time, and are not using a random IV in order to get ...


4

Does anyone know of some document or tutorial that gives a worked example of each step in using SHA3-512 to generate a digest of the message "" (or some other short message), giving detailed step-by-step values for all variables in the algorithm? What you are looking for is called a "test vector" (with intermediate values) and NIST offers them for all their ...


3

RFC4868 is not the HMAC RFC, which is actually RFC 2104. 4868 refers to the use of HMAC within IPSEC, which is why there is a key length restriction. The maximum length key that can be used internally with HMAC-SHA256 is equal to the block size, 64 bytes or 512 bits. This can be useful in cases where the key is not full entropy such as the shared secret ...


3

Perhaps obvious, but couldn't you download other implementations, design a test set of your own, and run it through multiple implementations to verify the same results? There are these implementations: http://sourceforge.net/projects/fortunaprng/ https://github.com/dlitz/pycrypto/tree/master/lib/Crypto/Random/Fortuna If system entropy is an issue, you ...


3

Maarten's answer is totally right, but I would like to add a very convenient link: The python library pyca features a Test vectors page in their documentation, which gives a very nice overview of test vector sources for all the schemes they have implemented.


3

I wound up finding RFC 7539, and using the test vector from section 2.8.2 of that document. I present the same vector here, in a more code-friendly format: # test vector courtesy https://tools.ietf.org/html/rfc7539 vector = { key: "808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9f", input: "...


3

For the complete picture, as was pointed out, you should use the final RFC, not drafts. There are two relevant RFC here: RFC 7539 describes the stream cipher ChaCha20, the MAC algorithm Poly1305, and an Authenticated Encryption with Associated Data mode that combines ChaCha20 and Poly1305 in a safe way (in particular, it uses ChaCha20 to provide the secret ...


2

It is for the 1st version of 3DES which is only using the same key three times (3DES-EDE1) Which is equivalent to DES (I think they did that so you could use 3DES to exchange with someone using DES). There are 3 different versions (or ways of using DES). EDE3 is the strongest with 3 different keys being used.


2

I don't unfortunately know a good set of preexisting test vectors for this curve. Instead I decided to advice you how you can generate them yourself. Hope this helps. Some (fairly recent) OpenSSL versions are familiar with secp256k1 curve. You may use e.g. OpenSSL's command line tool openssl's commands ecparam, ec, dgst to generate key pairs, parameter ...


2

Testing properly implemented Fortuna is little different than testing any alleged cryptographically secure random number generator. The fundamental problem is a philosophical one, as well as a practical one. For simulation it may be sufficient to choose digits from pi, which is universally believed to be randomly distributed. But, as a cryptographic key or ...


2

Robert Brown of Duke University has an excellent test suite called "Dieharder". Supposedly this is the most stringent battery of PRG tests available. I have never used it but it will be worth your while to check it out.


Only top voted, non community-wiki answers of a minimum length are eligible