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 do I reset a password of slot for soft-token after removing the token
Subrata Mazumdar wrote: nsCOMPtrnsIPK11Token softToken; rv = pkcs11Slot-GetToken(getter_AddRefs(softToken)); softToken-Login(PR_FALSE); // prompts for initializing password . . . softToken-Reset(); // expected that token/slot password would be in the uninitialized state SECMOD_CloseUserDB( softTokenSlot); When th slot is closed, the token is removed but the slot is still there with the old password. You need to make sure you free all your references to your slot (including the slot itself and objects associated with the slot). That is likely what's causing you to create a new slot in your step below. This doesn't explain why softToken-Reset() is not working. The base code is in PSM, but I believe it just maps to a token reset at that PKCS #11 level. Tracing the error code from NSC_InitToken() might be instructive here. When I open a new soft-token using SECMOD_OpenUserDB() with a new token name, it is installed in existing the empty slot with the old slot name and protected with the old password. How do I take the empty slot to uninitialized state so that 'nsIPK11Token.login()' does not prompt for the old password while asking for the new password? Thanks for your help. -- Subrata ___ 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
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: Problem with JSS on Ubuntu
Marcin T wrote:
Hi
I finally discovered what is the issue here. In appears that in case
of unsigned applets, the code is unable to access SunJCE provider
You need to spend your time on signing the applet correctly.
You really don't want to get unsigned applets working by modifying your
java.policy
for the long term, as this grant permission to all applets. Now when you
surf the web any
applet that is executed has the extra permissions that you configured:
As a workaround I have set up the following policies using Policy
Manager:
grant {
permission java.security.SecurityPermission
putProviderProperty.SunJCE;
};
grant {
permission java.lang.RuntimePermission getProtectionDomain;
};
grant {
permission java.lang.RuntimePermission
accessClassInPackage.sun.security.*;
};
I don't know how insecure my actions are, but this definitely fixed
problems with applets under SSL / HTTPS.
Security - Signed Applets forum:
http://forums.sun.com/forum.jspa?forumID=63start=0
http://java.sun.com/javase/6/docs/technotes/guides/plugin/
http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/security.html
-glen
Feel free to send me your ideas how to fix this issue in more elegant
way.
Best,
Marcin
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
___
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
New documentation: NSPR functions required for using NSS
As part of the work to include NSS in LSB 4.0, I created a list of NSPR functions required for using the NSS SSL functions at http://developer.mozilla.org/En/NSS_reference/NSPR_functions I generated this list by inspecting the source code of libcurl, nss_compat_ossl, mod_nss, and the NSS test programs selfserv, tstclnt, strsclnt, vfyserv, and vfychain. Note, in particular, that I documented the PR_ImportTCPSocket function, giving an official blessing to use this function when you know what you're doing. Please let me know if I have explained the caveats adequately without discouraging people from using this convenient function under the right circumstances. Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New documentation: NSPR functions required for using NSS
I'm pretty sure there are some things that can be done to put a TCP socket into a state that's inappropriate for O_NONBLOCK mode, but I can't think of any off the top of my head. Is there a reference somewhere that lists the kinds of things that a programmer needs to avoid? If there is, could the documentation page link to it, or import it? Thank you very much for documenting this! -Kyle H On Mon, Sep 8, 2008 at 4:35 PM, Wan-Teh Chang [EMAIL PROTECTED] wrote: As part of the work to include NSS in LSB 4.0, I created a list of NSPR functions required for using the NSS SSL functions at http://developer.mozilla.org/En/NSS_reference/NSPR_functions I generated this list by inspecting the source code of libcurl, nss_compat_ossl, mod_nss, and the NSS test programs selfserv, tstclnt, strsclnt, vfyserv, and vfychain. Note, in particular, that I documented the PR_ImportTCPSocket function, giving an official blessing to use this function when you know what you're doing. Please let me know if I have explained the caveats adequately without discouraging people from using this convenient function under the right circumstances. Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New documentation: NSPR functions required for using NSS
On Mon, Sep 8, 2008 at 5:14 PM, Kyle Hamilton [EMAIL PROTECTED] wrote: I'm pretty sure there are some things that can be done to put a TCP socket into a state that's inappropriate for O_NONBLOCK mode, but I can't think of any off the top of my head. Is there a reference somewhere that lists the kinds of things that a programmer needs to avoid? If there is, could the documentation page link to it, or import it? I haven't written such a reference. I don't know anything that can be done to put a TCP socket into a state that's inappropriate for O_NONBLOCK off the top of my head either. Rather than listing the kinds of things that a programmer needs to avoid, perhaps we can require the caller to return the native socket to the pristine mode it was created in by the socket() system call? This could be overly restrictive because some modes, such as the close-on-exec flag, won't interfere with the O_NONBLOCK mode. Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New documentation: NSPR functions required for using NSS
On Mon, Sep 8, 2008 at 5:37 PM, Wan-Teh Chang [EMAIL PROTECTED] wrote: On Mon, Sep 8, 2008 at 5:14 PM, Kyle Hamilton [EMAIL PROTECTED] wrote: I'm pretty sure there are some things that can be done to put a TCP socket into a state that's inappropriate for O_NONBLOCK mode, but I can't think of any off the top of my head. Is there a reference somewhere that lists the kinds of things that a programmer needs to avoid? If there is, could the documentation page link to it, or import it? I haven't written such a reference. I don't know anything that can be done to put a TCP socket into a state that's inappropriate for O_NONBLOCK off the top of my head either. Rather than listing the kinds of things that a programmer needs to avoid, perhaps we can require the caller to return the native socket to the pristine mode it was created in by the socket() system call? This could be overly restrictive because some modes, such as the close-on-exec flag, won't interfere with the O_NONBLOCK mode. Wan-Teh What is the semantic if someone opens the TCP socket in O_NONBLOCK in the first place? (Also, I found http://www.faqs.org/faqs/unix-faq/socket/ section 2.9. It doesn't exactly help all that much in explaining what goes on, but does PR_ImportTCPSocket's implementation (and thus the entirety of NSPR) add something to handle SIGIO? Or is it more of a select() with a timeout of 0?) -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
