Nelson B Bolyard wrote:
Graham Leggett wrote, On 2008-09-06 12:51:I think a big source of confusion is that everything is an OID, or everything is a mechanism, but not all OID or mechanisms are relevant for every situation, and this isn't clear from each function call.I think this may only be true because of the involvement of PKCS5v2. If PKCS5v2 was not part of the problem space, I would have said that there was no need to use OIDs at all, none whatsoever. I would have said that PK11_ interfaces exist that can do everything you need with just mechanisms, and no OIDs.
I'm going to disagree with nelson here.Yes it's possible to use PKCS #11 mechanisms directly, but it's not the suggested way of doing it for most applications. OIDs are definately the way to go there. The reason for this is one of 'generality'. In most cases, at least for decryption, the application should not need to actually know the cipher that is being used. All the appropriate information can be encoded in the proper algorithm ID. pkcs #7 and company provide an easy way to wrap these, and if you support mechanisms in this way your application can support new.
OIDs are used because they are the standard mechanism to communicate cipher information in our standard protocols.
If you can capture the dead ends you went down, that would help us immensely in improving our documentation (and even layout).
The SSL library, in some sense, is a special case. Supporting new ciphers requires work at the SSL layer precisely because it uses PKCS #11 mechanisms directly (or more exactly because it uses a non-OID data to communicate cipher preferences).The SSL library, for example, manages to use many forms of encryption without ever identifying any of them with an OID. If I recall correctly, so does the SDR interface which is used to encrypt and decrypt users' web site passwords that are remembered by Firefox.
Adding new
SDR is fixed keys, where you just generate a random key, get and index and then use the index to encrypt/decrypt data. There is not key exchange, so data encrypted with and SDR key from one database is not decrypted by someone on another machine or even someone using the same machine, but a different database (or token).I would have recommended that you look at the SDR interface as an example of how to do what you wanted to do, simple encryption of a string with an algorithm of your choice and an arbitrary key. But SDR doesn't use PBE and hence doesn't use PKCS#5.
Currently we do not have tools to move these fixed keys around, but the NSS primitives are there to support those tools.
Yes, algorithm ID's is the one common method between all the various PBE mechanisms. Use of the algorithm ID allows us to use the same interfaces for the entire PBE set. This means applications that didn't support PKCS 5v2 in older versions of NSS, at least can decrypt PKCS 5v2 blobs without any changes.For example, the PK11_CreatePBEV2AlgorithmID function contains a SECOidTag prfAlgTag parameter, but what this parameter was (the pseudo random function) I only discovered after tripping over it mentioned in a section of the PKCS5 spec that I was reading looking for something else.The PKCS5v2 support is a recent addition to NSS. Apparently the new interfaces created for that rely on algorithm Ids, which include OIDs. I don't know if Algorithm Ids are an essential part of the definition of PKCS#5v2 (I don't recall and don't have time to go look right now), but if they are not, then I would imagine that the NSS team could add some additional functions to NSS's public API that allow the caller to specify mechanisms directly and avoid indirection through algorithm IDs and their associated OIDs.
That's because there is no Oid for DES3_ECB. there really isn't a case to use ECB mode except in wrapping keys.Completeness I guess - xml-security's API allowed you to choose both CBC and ECB modes, so I was trying to emulate the same thing.A design question: why do you want to use the ECB mode? In most applications, the ECB mode is less secure than the CBC mode.The only mechanism that I cannot find an oid for is CKM_DES3_ECB - do you know which SEC_OID_* macro I should be using?
. Although the XML spec may include ECB, I think people with more than a passing familiarity with encryption would not attempt to use it in any serious applications. So, you may be able to reach your goal more quickly with NSS if you can simply abandon the use of ECB and stick with CBC. This is just a suggestion, of course.
I would echo the suggestion.I would also point out that if you are using XML, you may actually be in the same situation as SSL, where you have a non-oid way of specifying crypto algorithms. In that case you have to have your own mapping, anyway, so mapping to PKCS #11 mechansim could very well be an option (though PKCS 5 and PKCS 5 v2 does purposefully support OIDS, so then you have the problem that you have more than one way to specify and encryption cipher --- this may be your real problem). Even in this case, I would be very relunctant to support both ECB and CBC modes, particularly with PBE mechanisms.
bob
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
