# Tag Info

12

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

7

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

6

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

5

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

5

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

5

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

4

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

4

Normally, test vectors, in particular test vectors for intermediate values, are to be found with whatever is the "official specification" for that algorithm. MARS has not been blessed with a standard (few algorithms are), so the "official specification" is what IBM distributes, in particular the MARS package (compressed archive). This package contains the ...

3

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' | ... 3 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 ... 3 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 ... 3 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 ... 2 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 ... 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 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. ... 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. 2 I've been looking for the test vectors also. https://github.com/NTRUOpenSourceProject/ntru-crypto/blob/master/reference-code/Java/Encrypt/build.xml refers to ""com.securityinnovation.testvectors.NtruEncryptTestVectorGenerator" " I haven't looked any deeper than this, but it looks like they don't publish test vectors, but give you a means of generating them ... 2 There are many sources presenting the test vectors. But you can also extract it from sourcecode implementations as opencores.org et al offer them… Plaintext: 0000000000000000 Key: 00000000000000000000 (80-bit) Round key 1: 0000000000000000 Round key 2: c000000000000000 Round key 3: 5000180000000001 Round key 4: 60000a0003000001 Round key 5: ... 1 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 = ... 1 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. 1 In the original paper (pp. 16) one can find the requested test-vectors. The paper includes test vectors for all four cases you request (one or both of key and plaintext are$00...00$or$FF...FF\$). The following table shows the test vectors: Plaintext | Key | Ciphertext ------------------|------------------------|----------------- ...

1

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

1

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.

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