A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.

# Tag Info

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 ...

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

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 ...

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: ...

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

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

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

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 ...

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

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 ...

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

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

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 ...

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

There seem to be no standardized ElGamal test vectors available in the public domain. However, there are some ElGamal test vectors generated with libgcrypt 1.5.0 available in this fork of the pycrypto project.

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

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.

2

Yes. The stream is also in hexadecimal, as is the IV if used. The representation is just the output stream broken into 64-byte sections. Some of the tests output 512 bytes of stream, some output 131072.

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