Re: [openssl-users] Testing OpenSSL based solution
From: openssl-users On Behalf Of Marcus Vinicius do Nascimento Sent: Tuesday, May 12, 2015 16:50 I did some quick research and found this: http://en.wikipedia.org/wiki/Digital_Signature_Algorithm If my understanding is correct, the public key is (p, q, g, y). You might want to look at the actual standard, FIPS 186, free from NIST and referred to by wikipedia as well as easily searchable. The current version is revision -4, but the basic logic of DSA hasn't changed since -0 (although the sizes used have increased). Standardly a DSA public key is (parameters, y) where parameters is (p, q, g {, seed, counter}) where the optional fields in the parameters allow verification of the parameter generation process. OpenSSL does not use that option, so it uses only p,g,q and y. See below. The private key would be x, such that y = g^x mod p. Is there some way to generate both public and private keys using OpenSSL, based on p, q, g and y? You cannot recover the private key from the public key for any secure PKC scheme used with appropriate sizes. DSA is a secure scheme, and DSS and these test cases use appropriate sizes. De: openssl-users Em nome de Marcus Vinicius do Nascimento Enviada em: terça-feira, 12 de maio de 2015 17:06 I tried using Y as the public key, but ssl seems not to accept that. From the FIP file: snip So I tried reformatting Y to pass it to PEM_read_bio_DSAPrivateKey. Converting Y to Base64 = snip Reformatting in PEM format = -BEGIN DSA PRIVATE KEY- snip [doesn't work] As above, the public key requires all of p,q,g and y, not just y. The private key would require x as well, and you don't have x. For public keys for _all_ algorithms in files including PEM OpenSSL uses the format standardized by X.509 called SubjectPublicKeyInfo or SPKI for short, which is an ASN.1 sequence containing an AlgorithmIdentifier which is a(nother) sequence containing an OID identifying the algorithm and an optional parameters field whose type depends on the algorithm, followed by a BITSTRING containing a nested encoding of the public key value relative to the parameters for that algorithm. For DSA, the OID identifies DSA, the parameters are a sequence of three INTEGERs for p,g,q, and the nested key encoding is just an INTEGER. All elements in ASN.1 use a TLV (tag, length, value) encoding, and INTEGER (thus) consists of a tag octet of 02 specifying integer, a length whose length itself varies depending on the length it encodes, and a value field which for INTEGER is a _signed_ big-endian binary number. Since the particular y you tried to encode below happens to have a magnitude size of 1024 bits, a multiple of 8, it requires a leading sign octet of 00. So does g in this case, and p and q by design (they are specified with magnitude sizes which are multiples of 8, and indeed of 32). See rfc 5280 for the generic SPKI format, and rfc 3279 (referenced there) for the specifics for several algorithms including DSA. Note that the PEM type is just BEGIN/END PUBLIC KEY (no DSA) because as above the format handles all algorithms. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Testing OpenSSL based solution
I'm working on a C++ security library solution that uses openssl internally. It offers Sign/Verify, Digest and Encrypt/Decrypt as its features (please check available methods below). I'm using FIPS 2.0 test vectors to validate my library, but I'm having a bit of trouble with that. Testing Digest is easy. It is just a matter of providing any data and check whether the returned value matches expected values. FIPS 2.0 is working just fine here. Testing Sign/Verify is a whole different story. My understanding is that algorithms use random parameters to sign data, so two consecutive calls to sign with the same parameters would yield different results. I guess I have to sign some data, and verify it to make sure that's working. FIPS provides testing parameters that are not trivial (message, y, r, s) and I'm not sure how to handle them. Is it possible to use those parameters considering my API (check below)? I haven't tried testing the encrypt/decrypt methods, since I'm stuck in the Sign/Verify. Do you think using FIPS test vectors to validate my solution is a good/feasible approach? Is there any better/simpler testing approach? This is my API: Sign/Verify: std::string /* B64 */ sign( std::string algorithm, std::string private_key /* B64 */, std::string data /* B64 */, bool error ); bool verify( std::string algorithm, std::string data /* B64 */, std::string signature /* B64 */, std::string public_key /* B64 */, bool error ); Algorithims: SHA1, SHA256, SHA384, SHA512 with RSA, ECDSA and SHA1withDSA. Digest: std::string /* B64 */ digest( std::string algorithm, std::string data ); Algorithms: SHA1, SHA256, SHA384, SHA512. Encrypt/Decrypt: std::string /* B64 */ encrypt( std::string algorithm, bool padding, std::string data /* B64 */, std::string key /* B64 */ ); std::string /* B64 */ decrypt( std::string algorithm, bool padding, std::string data /* B64 */, std::string key /* B64 */ ); Algorithms: des-ede-cbc, des-ede, des-ede-cfb, des-ede-ofb, des-ede3-cbc, des-ede3, des3, des-ede3-cfb, des-ede3-ofb, aes-[128|192|256]-cbc, aes-[128|192|256], aes-[128|192|256]-cfb, aes-[128|192|256]-cfb1, aes-[128|192|256]-cfb8, aes-[128|192|256]-ecb, aes-[128|192|256]-ofb. Thanks very much, Marcus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Testing OpenSSL based solution
What Mr. Salz refers to by Verification should be okay is probably this: Yes and Mr. Salz greatly appreciates Mr. Bohm's elaboration. :) Lest the humor be misunderstood: yes, you're right, thanks for explaining. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Testing OpenSSL based solution
On 12/05/2015 20:10, Salz, Rich wrote: You can't easily have test vectors for DSA signatures since they include a random. Any test vector would have to include the random, and any API would have to be able to accept the random as part of the sign API. Verification should be okay. What Mr. Salz refers to by Verification should be okay is probably this: You can have test vectors in the form of known good signatures withpublic keys listed in the test vector. For DSA, those would be the (message, y, r, s)quads mentioned by the OP (y is the public key, (r, s) is the signature), dependingon his class library, it might be possible to reformat those vectors to the formatused by his code for real messages. The importance of such test vectors is to detect if an implementation is accidentally implementing a different signature algorithm (such as accidentally appending a 0 byte to each message both during signing and verification). This would not be detected by signing and verifying sample messages with random parameters. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Testing OpenSSL based solution
On Tue, May 12, 2015 at 06:10:39PM +, Salz, Rich wrote: You can't easily have test vectors for DSA signatures since they include a random. Any test vector would have to include the random, and any API would have to be able to accept the random as part of the sign API. Verification should be okay. It'd be nice to have derandomized *DSA forms for OpenSSL. CFRG is on the case, thankfully, so eventually there should be a derandomized ECC signature scheme in OpenSSL. (Assuming the consensus ends up being in favor of having a deterministic, state-less signature scheme.) Nico -- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Testing OpenSSL based solution
You can't easily have test vectors for DSA signatures since they include a random. Any test vector would have to include the random, and any API would have to be able to accept the random as part of the sign API. Verification should be okay. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users