# Tag Info

11

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

5

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

5

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

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

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

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

1

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

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