>>> 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?
>
> No. As for EC DSA, GOST private key is big integer, GOST public key is
> a EC base point multiplied by a private key. As noted above, the
> signature algorithm is different. Also GOST places some forcible
> restrictions on algorithm parameters. For instance, EC must be prime,
> not binary.
OK, you may want to just call it an EC key then (at least inside the
token) unless there is additional information that comes with the key
that EC doesn't have and you need to store.
>
>>
>>> 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).
>
> The main reason is to ship a working solution ASAP. Developing an own
> PKCS#11 module seems to be more complicated and error-prone task, than
> adding support to "softoken".
It the goal is to get a working prototype ASAP, then you are doing
exactly the right thing. If the goal is to get something *shipping*
ASAP, then I strongly suggest going the external token route. It will be
longer because you would be forging new ground, but it will ultimately
be shorter. You are looking at a year plus for any generally available
softoken releases. Your timing on softoken changes can only be
marginally worse. we just froze softoken in October. The release branch
will not get any patches on it except emergency security fixes that we
can get lab approval for. Certainly anything as big as putting in a new
algorithm would have to go on the SOFTOKEN_3_13 branch, which would
release on the next FIPS update.
This FIPS churn is precisely why I strongly urge new non-FIPS algorithms
to live outside of softoken. We will likely move SEED and Camilia
outside as well. Unfortunately if you need to actually store private
keys in the database, then you are pretty much stuck with softoken.
>
>>
>> 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.
>
> At the moment, I do not understand well what is a legacy and new
> database formats, and need to improve my knowledge.
>
> But, given your explanation, I could conclude: there should not be a
> difference in handling CKA_NETSCAPE_DB for various private key types.
code under the legacydb directory. It's the old berkeley db version of
our database which is not multi-process safe. Unfortunately most
applications still use it, though the use of the sql database is increasing.
>
> However, here is a what sftk_unwrapPrivateKey @ pkcs11c.c does
> (pseudo-code):
>
> switch( private_key_type ) {
> case RSA_KEY:
> if(sftk_hasAttribute(key, CKA_NETSCAPE_DB)) {
> sftk_DeleteAttributeType(key, CKA_NETSCAPE_DB);
> }
> ...
> case DSA_KEY:
> case ECC_KEY:
> crv = (sftk_hasAttribute(key, CKA_NETSCAPE_DB)) ? CKR_OK :
> CKR_KEY_TYPE_INCONSISTENT;
>
> Why this difference is needed ?
RSA already has enough information to reconstruct both the DB key and
the and the public key from the rest of the PKCS #11 attributes set in
the private key.
>
>>
>> I presume the question is generated by your work on GOST signing (as
>> opposed to verification?).
>
> Yes, it is.
OK, cool.
bob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
