On 10/06/2009 01:14 AM, Konstantin Andreev wrote: > Hello, Robert. > > On Mon, 10 Oct 2009, Robert Relyea wrote: >> On 10/05/2009 09:27 AM, Konstantin Andreev wrote: >>> >>> Could you, please, advice, how should I handle CKA_NETSCAPE_DB for >>> GOST private keys ? >> >> GOST private key? Are you talking about a new asymmetric algorithm >> (a.la. RSA and DH)? If so, then you would need to worry about private >> keys. If you are just talking about a symmetric algorithm, then there >> is no need. You're key is a secret key, and should be handled >> automatically. > > Yes, the GOST (i.e. "Russian Federation National Standard") suite > includes asymmetric digital signature algorithm. That is what > referenced as "GOST R 34.10-2001" in RFC documents, and what I am > talking about. OK, we're just talking signature here, then. > > Basically, this is an elliptic curve algorithm, but GOST signature > slightly differ from X9.62 EC signature. GOST digital signature is not > affected by Certicom patents and free for use. Even more, in Russia, > it is mandated for use in government organizations and "working for > government" organizations.
Thanks. So the actual signature algorithm is different than EC DSA, but it works on EC curves. Is there anything different about the key itself? > From NSS perspective, GOST ECC signatures can't be intermixed with > X9.62 signatures, because all data formats are completely different. > You can refer to patch 1 in bug 518787 for some examples of this > difference. > > In the "softoken", CKA_NETSCAPE_DB is applied to private keys in a > various mystic ways. It's unclear, which concern it has to GOST > private keys. Could you, please, advice ? You can still supply asymmetric algorithms from an external module. -- remember that will be faster coming up. That being said, I can see why you may want to use softoken (so your keys will wind up in softoken's database). CKA_NETSCAPE_DB is the database key (key as in lookup key, not crypto key) that the object will be stored under. This is typically the public key (so that NSS can present both the private and public keys, even though only the private key is stored in the database). This is only needed for the old dbm database, the new database format just stores the value, but never needs or uses it. I presume the question is generated by your work on GOST signing (as opposed to verification?). bob > Best regards, > -- > Konstantin Andreev, software engineer. > Swemel JSC
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
