Re: How does PK11_GetPadMechanism work?
Nelson B Bolyard wrote: 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. 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. 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. The OpenSSL docs said Newer applications should use more standard algorithms such as PKCS#5 v2.0 for key derivation, and as this was new code, and as interoperability was important, I decided to follow the advice as it seemed sensible. I did see that the PKCS5v2 function has only been available since v3.12, which is relatively new. So far 3DES/CBC and AES256/CBC interoperate between OpenSSL and NSS without an issue, which I think is good enough for now for what we need it for. Regards, Graham -- 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
Re: How does PK11_GetPadMechanism work?
Graham Leggett wrote: 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. 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? The PK11_MechanismToAlgtag function for CKM_DES3_ECB returns SEC_OID_UNKNOWN. So ECB mode is used exclusively for key wrapping. There isn't a separate algoID tag for it. In general we try to use the OID mappings internally because that is what can be coded. There is no definition for using ECB mode in any type of PKCS #7 encodings, so there is no mapping. Typically things proceed from the CBC mode of block ciphers. bob 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
Re: How does PK11_GetPadMechanism work?
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, 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. 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). Adding new 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. 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). Currently we do not have tools to move these fixed keys around, but the NSS primitives are there to support those tools. 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. 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. 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. 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. 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? That's because there is no Oid for DES3_ECB. there really isn't a case to use ECB mode except in wrapping keys. . 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
Re: How does PK11_GetPadMechanism work?
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. 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. 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. 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. 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. 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. 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? The PK11_MechanismToAlgtag function for CKM_DES3_ECB returns SEC_OID_UNKNOWN. NSS exists primarily to support the implementation of standardized communication protocols such as TLS and CMS (S/MIME). None of those protocols ever uses ECB (IINM), and so support for ECB may be minimal or outright lacking. 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. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How does PK11_GetPadMechanism work?
2008/9/6 Graham Leggett [EMAIL PROTECTED]:
Hi all,
Using PK11_GetPadMechanism(), and passing it a cipher mechanism, it as I
understand returns a variation of the mechanism capable of supporting
padding.
Is this understanding correct?
I have noticed that when CKM_AES_ECB is passed to PK11_GetPadMechanism, I
get the same mechanism in return.
Does this mean that CKM_AES_ECB does not support padding?
Or does this mean that CKM_AES_ECB already supports padding and there is no
need to switch it on?
For questions like this, you can sometimes find the answers in
the PKCS #11 standard.
Searching for the string CKM_AES_ECB in PKCS #11 v2.20,
I found Section 12.12.4 AES-ECB on page 270, and its Table
86 shows that for C_Encrypt, the input must be a multiple of
block size. Contrast this with Table 88 in Section 12.12.6
AES-CBC with PKCS padding. I concluded that CKM_AES_ECB
does not do padding. The caller is responsible for padding
the input, if necessary, to multiples of block size.
I found the best answer to your question in the block comment
before PK11_GetPadMechanism:
http://mxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11mech.c#1666
1666 /* Determine appropriate blocking mechanism, used when wrapping
private keys
1667 * which require PKCS padding. If the mechanism does not map to a padding
1668 * mechanism, we simply return the mechanism.
1669 */
1670 CK_MECHANISM_TYPE
1671 PK11_GetPadMechanism(CK_MECHANISM_TYPE type) {
So if the return value of PK11_GetPadMechanism equals the input,
it means the input doesn't support padding. If the return value is
different from the input, the return value is a variation of the input
capable of supporting padding.
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.
Wan-Teh
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How does PK11_GetPadMechanism work?
Wan-Teh Chang wrote:
For questions like this, you can sometimes find the answers in
the PKCS #11 standard.
Searching for the string CKM_AES_ECB in PKCS #11 v2.20,
I found Section 12.12.4 AES-ECB on page 270, and its Table
86 shows that for C_Encrypt, the input must be a multiple of
block size. Contrast this with Table 88 in Section 12.12.6
AES-CBC with PKCS padding. I concluded that CKM_AES_ECB
does not do padding. The caller is responsible for padding
the input, if necessary, to multiples of block size.
Hmmm - I spent last weekend going through the PKCS #11 standard, which
defines an API that seems different to the PK11_CipherOp and friends
that I was seeing in the examples.
I found the best answer to your question in the block comment
before PK11_GetPadMechanism:
http://mxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11mech.c#1666
1666 /* Determine appropriate blocking mechanism, used when wrapping
private keys
1667 * which require PKCS padding. If the mechanism does not map to a padding
1668 * mechanism, we simply return the mechanism.
1669 */
1670 CK_MECHANISM_TYPE
1671 PK11_GetPadMechanism(CK_MECHANISM_TYPE type) {
So if the return value of PK11_GetPadMechanism equals the input,
it means the input doesn't support padding. If the return value is
different from the input, the return value is a variation of the input
capable of supporting padding.
Ah ok - I have up till now being looking for comments and documentation
within the header files rather than the code itself. Documentation does
exist in the header files, although nothing that explains how different
things relate to one another.
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.
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.
I think it would help immensely if there were doxygen (or whatever other
tool) comments in the header files to generate docs from automatically.
This is typically the starting point for me when looking for information
about a function that wasn't found in the man pages.
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.
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.
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?
The PK11_MechanismToAlgtag function for CKM_DES3_ECB returns
SEC_OID_UNKNOWN.
Regards,
Graham
--
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
Re: How does PK11_GetPadMechanism work?
2008/9/6 Graham Leggett [EMAIL PROTECTED]: Hmmm - I spent last weekend going through the PKCS #11 standard, which defines an API that seems different to the PK11_CipherOp and friends that I was seeing in the examples. Right. Each crypto module exports the PKCS #11 API, with function names like C_Encrypt. The PK11_ functions in NSS allow you to manage and use multiple crypto modules. They dispatch crypto operations to the appropriate the crypto modules. They're also supposed to hide the complexity of the PKCS #11 API, but some of it still leaks through. Ah ok - I have up till now being looking for comments and documentation within the header files rather than the code itself. Documentation does exist in the header files, although nothing that explains how different things relate to one another. Ideally we should move the comments that document the functions to the header files or our documentation websites. Our documentation is adequate in some areas but is lacking in other areas. The PK11_ functions for crypto operations are an area that need more documentation. 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. 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. I think it would help immensely if there were doxygen (or whatever other tool) comments in the header files to generate docs from automatically. This is typically the starting point for me when looking for information about a function that wasn't found in the man pages. Our team has recognized the need for better developer documentation. I hope we will have some results soon. For now, I highly recommend using our MXR source code search to supplement the documentation: http://mxr.mozilla.org/security/ 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? The PK11_MechanismToAlgtag function for CKM_DES3_ECB returns SEC_OID_UNKNOWN. I don't know either. Does anyone know? Does the lack of a SECOidTag for CKM_DES3_ECB prevent you from using some NSS functionality? I did some web searches for the OID. The OID for DES-EDE is 1.3.14.3.2.17: http://www.alvestrand.no/objectid/1.3.14.3.2.17.html But I'm not sure if that's the ECB mode. NSS's SECOidTag for this OID is SEC_OID_DES_EDE. In our OID table, this OID doesn't correspond to any PKCS #11 mechanism: http://mxr.mozilla.org/security/source/security/nss/lib/util/secoid.c#611 611 OD( desede, SEC_OID_DES_EDE, 612 DES-EDE, CKM_INVALID_MECHANISM, INVALID_CERT_EXTENSION ), Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
