http://blog.gmane.org/gmane.comp.mozilla.crypto hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.mozilla.crypto/16766 <pre>Hi Wan-Teh, Nelson, could it be that this error is also raised by the client if the client can not 'participate' in ssl client-auth? Unfortunately I only got a text-output of 'ssldump', not sure if this is would be helpful. The end of the handshake shows ... 1a0: f3 6e fc 04 ab 79 e1 13 | .n...y.. 0: 0d 00 2b 36 | ..+6 type = 13 (certificate_request) length = 11062 (0x002b36) CertificateRequest { certificate types[3] = { 01 02 40 } certificate_authorities[11056] = { &lt;&lt;&lt;&lt;&lt;....List Truncated....&gt;&gt;&gt;&gt;&gt; } } 0: 0e 00 00 00 | .... type = 14 (server_hello_done) length = 0 (0x000000) } } ] --&gt; [ (7 bytes of 2) SSLRecord { [Mon May 14 13:25:27 2012] 0: 15 03 00 00 02 | ..... type = 21 (alert) version = { 3,0 } length = 2 (0x2) fatal: bad_certificate 0: 02 2a | .* } Interestingly enough the community member told be that this error does not happen with NSS: 3.12.8 NSPR: 4.8.6 TIA, Bernhard Am 5/9/12 7:43 PM, schrieb Wan-Teh Chang: </pre> Bernhard Thalmayr 2012-05-21T12:21:25 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16765 <pre> QQ or EMail OK? na2650945&lt; at &gt;163.com </pre> chu wang 2012-05-14T12:19:33 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16764 <pre>I really don't understand what you are speaking. I'm in Beijing , so could you give me your cell phone number? If so, I will call you later. On 05/14/2012 01:38 PM, chu wang wrote: </pre> wdeng 2012-05-14T08:47:20 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16763 <pre>Yesterday thoughts: Some policies say "Before signing, a preview of what is going to be signed must be shown to the user". If we use something like: signedData=sign(key,dataToBeSigned) this could show, for example, a pdf preview of what is being signed. I love that idea, but what if i actually want to sign a bunch of documents? for(i=0;iz10;i++){ signedData=sign(key,dataToBeSigned[i]) } will show 10 previews, and thats horrible. What about using another API instead? signInit(key) //key to sign signAdd(data) //one call for each document to be signed in this block signFinal() //show a single preview for all documents in this block and do signing (of approved/selected) there could be also a sign wrapper like: sign(key,data){ signInit(key) signAdd(data) signFinel() //preview &amp; sign } BTW: i also realized that server signature validation requires public key, so privacy issues relating public key are impossible to avoid. Open to critics, comments and suggests, and a happy monday to all! </pre> helpcrypto helpcrypto 2012-05-14T06:53:49 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16762 <pre>Hi all. I want to by the NSS calls the P11 module. So I have some quessions. 1.PKCS #11 Conformance Testing where download. 2.How to compile NSS,Which have detailed guidance document? 3.Other browsers, such as chorme also supports NAPI, how to call the P11, but also through the NSS? 4.What are the advantages of the NSS call P11 NPAPI? Thanks. Firefox Chinese little information. If there is something wrong, please forgive me. </pre> chu wang 2012-05-14T05:38:14 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16760 <pre> Nelson is right. I looked into a check we added recently for 3). It was added in NSS 3.12.7: https://bugzilla.mozilla.org/show_bug.cgi?id=554354 Since you're using NSS 3.12.5.0, that makes 3) less likely, but still possible. Yes. To track this down, we need the server's certificate chain and the "Server Key Exchange" handshake message, if it is used. Wan-Teh </pre> Wan-Teh Chang 2012-05-09T17:43:01 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16759 <pre> Bernhard, I think the most likely explanations are these: 1) Server certificate has a public key that is too small, too large, has a too small public exponent (if RSA), an unknown key type, or a key for an Elliptic Curve that is not supported by NSS. 2) Some other certificate in the server's cert chain has one of the above problems. 3) The server is attempting to use "Server Key Exchange" for forward secrecy, and the key it is offering for that purpose has one of the problems mentioned above. 4) The server is selecting a cipher suite that is incompatible with the type of key in its public key certificate. Ii suggest you use tcpdump or ssltap to get a trace of your own. Regards, /Nelson </pre> Nelson B Bolyard 2012-05-09T02:33:40 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16758 <pre>Hi, Wan-Teh Chang schrieb (07.05.2012 20:39 Uhr): Is there anyone who can say for sure, if this is true or not? Is there a better place to ask? In Firefox it should work this way, according to http://mike.kaply.com/2012/03/30/customizing-firefox-default-profiles/ "If you add additional files into this directory, those files are copied into the default profile along with the rest of the files. This is most commonly used if you want to have default certificate databases. I’ve seen cases where someone started Firefox, added the certificates and certificates authorities they needed and then copied the various *.db profiles from their profile and put them in the default profile so all their users would get them." Marc </pre> Marc Patermann 2012-05-08T13:22:19 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16757 <pre>Hi experts, an OpenAM community member is using OpenAM policy agent to connect to an ssl-secured server. The policy agent uses NSPR 4.8.2, NSS 3.12.5.0 optimized build for Linux (RHEL) 64bit. If the agent tries to open a connection to a specific, ssl-enabled OpenAM server, error '-8152' is raised. What might be the root-cause for this error? Could I get some additional output from an optimized build or do I really need a 'DEBUG' build to leverage NSS environment variables (https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables)? Interestingly the same agent can connect to other ssl-enabled servers. Unfortunately the community member will / can not provide a network trace showing the handshake messages. TIA, Bernhard </pre> Bernhard Thalmayr 2012-05-08T11:53:45 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16756 <pre> Any comments? </pre> helpcrypto helpcrypto 2012-05-08T07:34:16 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16755 <pre>On Mon, May 7, 2012 at 9:20 AM, Marc Patermann &lt;hans.moser&lt; at &gt;ofd-z.niedersachsen.de&gt; wrote: Hi Marc, Perhaps the cert8.db file in defaults/profile in the program directory is not being used by Mozilla programs? If that's true, then I'm afraid that you will need to add your CA to every profile, rather than relying on defaults/profile in the program directory. Wan-Teh </pre> Wan-Teh Chang 2012-05-07T18:39:53 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16754 <pre>Hi, I posted my issue on Thunderbird-Enterprise before and Ludovic Hirlimann sent me here. I created an own CA and put the cert in cert8.db by GUI in Thunderbird 10 ESR. As far as I understand it, the way to go is to put the corresponding cert8.db file in defaults/profile in the program directory. (Which works for mimetypes.rdf.) For what I tested it does not work. On a blank profile cert8.db is always the original file, my CA is never included. If I copy back cert8.db by hand, the CA is in there. So the file itself is fine, but it seams to be never used. What did I do wrong? Marc </pre> Marc Patermann 2012-05-07T16:20:13 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16753 <pre> On Thu, Apr 26, 2012 at 12:32 AM, helpcrypto helpcrypto &lt;helpcrypto&lt; at &gt;gmail.com&gt; wrote: I observe that yes, this is "base64 encoding the data to be signed before the signature is created". Huh. Someone who thinks like I do. This information has value, thus this information must be protected. Fortunately, I have something for that. Behold: the Identity Escrow Agent. This is a certifier who would take { your full certificate, a new public key }, the set signed with both asserted keys (axiomatic binding), then create a certificate around the new public key which says "I know who this is, but I shall not tell anyone except legitimate state authority." The idea is that site owners would be able to start requiring this kind of certificate, so that they can hold spammers and vandals accountable -- without becoming private information trustees and becoming subject to various states' felonization of handling personal information with less than PCI 2.0 controls. This is a use which is far less dangerous to the broad swath of Mozilla's users than the false google.com certificate, and which has a much smaller exposure if the service is ever compromised. There would be no authoritative binding information within the escrow certificate, which would mean that it could only really be appropriate for establishing new non-fiduciary service relationships -- but this is a usage which has no current expression, and which I think would bypass many if not most of the issues preventing consumers and site owners from seriously looking at cryptographic solutions. (It would definitely bypass all of mine.) -Kyle H </pre> Kyle Hamilton 2012-05-04T06:05:15 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16752 <pre> On Thu, May 3, 2012 at 4:27 PM, Wan-Teh Chang &lt;wtc&lt; at &gt;google.com&gt; wrote: GenerateKeyPair(purpose:keyEncryption) GenerateKeyPair(purpose:Signature) I think this is due to France, and legacy requirements for different caps on encryption versus signature key strengths. I don't know if these are still concerns. This is not correct for EC. To do PKEncrypt there, you must have both the source private key and destination public key available to perform ECDH key agreement. Then, put that agreed value through a key derivation function (digest), and finally symmetrically encrypt the random message symkey with the derived symkey. There is no reversible transform from something which can be calculated solely from the public key, unlike RSA. Please implement RSA and DSA with a second, null parameter, so that this use can be enabled for EC. ALGORITHM_ECDSA should be in there as well. However, I do not agree with the idea of enumerating algorithms and modes separately. Down that path lies ECB and non-KDF agreed key usage. Sign needs to know some of the metadata associated with the keyID, I should think? Particularly for ECC certificates, SEC1 specifies an alternate encoding where the parameters are inherited from the certifier. If NSS stores these parameters for the private key regardless, I shall withdraw this objection. -Kyle H </pre> Kyle Hamilton 2012-05-04T05:45:00 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16751 <pre> Bob, Thank you!!! You are right. I'm faking the dynamic memory allocation with a static one and with some other tweaks. Ofcourse, I've modified mpi as well to get this work. I am using the data allocation. I will start working on this and get back to you. Regards, Vejey </pre> VJ 2012-05-04T05:48:05 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16750 <pre>David, I'll go into my vision of what I aspire to ("The Truly Universal PKI") in another message. Why I focus on what I do may become clearer then. tl;dr: 1. CMS is the primary motivator for BER indefinite reading, if not writing/digesting. 2. To prevent ECB and non-KDF key agreement, enumerate values for { algorithm, mode } and { keyAgreement, derivationFunction } tuples. This will prevent naive implementations of ECB and non-KDF key agreement in JavaScript or other clients. 3. Never allow non-Mozilla-implemented digest objects to provide any digest value for a signature, without a preference. 4. I wish for a truly expansive and comprehensive API. 5. Instead of defaults, perhaps allow the author to ask for a specific type of algorithm and a minimum strength, using lower-case type codes and bit-strength numbers. -Kyle H On Fri, Apr 20, 2012 at 8:40 PM, David Dahl &lt;ddahl&lt; at &gt;mozilla.com&gt; wrote: Aside from CMS (RFC5652), https://en.wikipedia.org/wiki/CAdES_%28computing%29 , a set of extensions to CMS (which permits BER, not mandating definite-length encoding) Basically, nearly every CMS-derived protocol requires the capacity to read, if not create, indefinite-length streams. (Time Stamp is notable exception) Elliptical Curve Diffie-Hellman Key Exchange has at least one unpatented, public domain implementation, in Daniel J Bernstein's Curve25519. http://cr.yp.to/ecdh.html for more information and source code. It is NOT a signature algorithm. It does not use the y coordinate, so there are no patent issues with key compression. Any 256-bit string is a valid private key. Any 256-bit string can be a valid public key. And it uses far fewer processor operations in key agreement on AMD64, and probably on other 64-bit platforms, than any other elliptical curve function of the same magnitude. Sure! My motive is to ensure that the maximum number of applications can be securely supported without having to revisit this API. Most specifically, I want to ensure that systems which greedily consume every cryptographic primitive and service (identity, timestamp, revocation), then turn around and ask "please sir, can I have some more?" can be implemented completely and securely in JavaScript addons. (Why? Because TTUPKI does so.) To this end, here is my wish list: Security principles: - Never allow a non-Mozilla-implemented object to calculate a digest which can possibly be provided to NSS for signing, without a preference:true. - Never create any means to create a new block symmetric cipher object which implements ECB mode. - Enumerate { algorithm, mode } tuples, not algorithms and modes, to avoid JavaScript ECB - Never create any means for a key agreement to be specified without a derivation function. - Enumerate { agreementAlgorithm, derivationFunction } tuples, not agreementAlgorithms and derivationFunctions, to avoid JavaScript non-key-derived implementation. Wish List: - Creation and management of new verification universes with only explicitly-added trust anchors, specified either by certificate reference or bare { algorithm, subjectPublicKeyInfo } tuple - ASN.1 generation/consumption, both BER and DER. (XER too, but less so) - CMS, for Time Stamp Protocol, both creation of requests and verification of tokens - OCSP, CRL generation/consumption - Generation, reference and use of multiple keypairs of varying types in crypto containers - Creation of new containers, setting their attributes, generating new keypairs of varying types within them, addition of arbitrary certificates associated with those keypairs, addition of multiple certificates associated with a given keypair, associating containers with the sites which requested their policy implementation, association of those sites' security policies with those containers (new NSS record type?) - Selection and use of both { userstring, derivationFunction } and { randomstring, derivationFunction } enumerated tuples. In the latter case, the randomstring tuple object should have a call to obtain the random string from which the return value was derived. - Selection and use of multiple asymmetric signature objects - Selection and use of multiple key exchange objects - Selection of atomic { symmetric algorithm, mode } tuple and its key length (no enumerated tuples which contain ECB) - Selection of and instantiation of multiple digest algorithm objects (only Mozilla-implemented for submission for signing, unless pref:true) - Selection and use of a key derivation function as part of the key agreement object (never permit key agreement objects to use null derivation functions) - Instantiation of multiple MACs over the same input stream - Signature over user blob, given the key, signature algorithm, and buffer of user blob (not "buffer of arbitrary digest over user blob") Make of it what you will. I expect that it's going to need to be revisited regardless of how much we put into it right now. :) Would those numbers be algorithm key lengths or cryptographic strengths? (log(2) magnitude number of operations which must be performed on average to either: recover the plaintext of a symmetrically-encrypted blob, recover the key of a symmetrically-encrypted blob, recover the private key of a public key, forge a signature, find a digest collision, or find a digest preimage) a) Algorithm key lengths require the site owner/addon author to keep updated when e.g. Mozilla deprecates algorithms which are shown to be broken. b) Cryptographic strengths would permit the client to select an appropriate algorithm given the input of the bits of security required for that policy. It would also permit the client to be updated with its own ideas as to what constitutes a given strength. However, it would also run the risk that non-client systems requiring interoperability will not be updated to get rid of broken algorithms. According to NIST (2011), 224-bit ECC is considered approximately as strong as 2048-bit RSA, and 256-bit ECC is approximately as strong as 3072-bit RSA. NIST also says that SHA1 shouldn't be implemented in new systems, because it provides less than 80 bits of strength in signatures and ~69 bits of strength against collisions. Asymmetric algorithm strength is best-case half of the algorithm key length (with EC), and much less (with others). Instead of defaults, perhaps the design might benefit from a set of tags (case-sensitive?) like: "sym256" minimum { symmetric algorithm, mode } tuple strength "asy128" minimum asymmetric strength "dgc128" minimum digest strength against collision "dgs128" minimum digest strength for signatures "mac128" minimum MAC strength This would permit addon developers to put their trust in Mozilla's professionalism and judgment, in staying abreast of current developments. -Kyle H-- dev-tech-crypto mailing list dev-tech-crypto&lt; at &gt;lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto</pre> Kyle Hamilton 2012-05-04T05:12:13 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16749 <pre> On Thu, Apr 26, 2012 at 12:32 AM, helpcrypto helpcrypto &lt;helpcrypto&lt; at &gt;gmail.com&gt; wrote: This is what the unique tags on ASN.1 UTF8String and IA5String and PrintableString and Shift-JIS and such are for, specifying the encoding. The certificate is not the public key. The public key is the only identity the computer can comprehend, and the certificate is metadata about the key which is (ideally) trusted for fiduciary work. The public key itself is its own identity as well, so your point doesn't even rely on having a unique hash. But! Here's someone who actually thinks like I do, that this information has value, and therefore this information must be protected. Fortunately, I have something for that. Behold: the Identity Trustee. This is a certifier which would accept your current certificate and a newly generated public key, both signed by both the certified keypair and the generated keypair. It would then sign a certificate for the generated public key which says, basically, "I know who this keyholder is, but I will only tell valid state authority." This would permit site owners to discourage spam and vandalism by knowing that they can hold the keyholder accountable if necessary, without disclosing the keyholder's (your) identity to every site, and without requiring the same key to be used on every site. Effectively, your public key would become your pseudonym. And, this is not a usage which would have the potential to endanger broad swaths of Mozilla's user base like the DigiNotar google.com certificate. -Kyle H </pre> Kyle Hamilton 2012-05-04T05:12:13 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16748 <pre>David, Here are my review comments on https://wiki.mozilla.org/DOMCryptInternalAPI: 1. I don't understand the difference between the two methods that generate key pairs: PKGenerateKeyPair SigGenerateKeyPair 2. PKEncrypt just need a public key, not a key pair. 3. I suggest not assigning 0 to any algorithm enumerator. This allows the use of 0 as an invalid value. We can't use -1 because the type is unsigned long. So ALGORITHM_RSA should be 1 and ALGORITHM_DSA should be 2. 4. Like PKDecrypt, Sign just needs aKeyID, which represents a private key. 5. Verify should take a public key. 6. The second arguments of Sign and Verify should have the same name (because the refer to the same thing) and the name should not imply it is encrypted (such as aPlaintext and aClearBytes). You can use 'message' as the argument name. 7. When verifying a MAC, the byte comparison must be constant time to avoid leaking timing info. Leaking timing info of MAC verification could be problematic in some situations. This issue is described in https://groups.google.com/group/keyczar-discuss/browse_thread/thread/5571eca0948b2a13 So I suggest adding a verify() method to the CryptoHmac interface, so that we can implement the verify() method with constant time byte comparison. Wan-Teh Chang </pre> Wan-Teh Chang 2012-05-03T23:27:07 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16747 <pre>This seems surprising with out modifying mpi. The underlying mpi code assumes that it can allocate data, so unless you are faking it out with some sort of manual allocator, I don't see how you can even get a basic RSA op to work. If you are trying to decode this in an enviroment that can't allocate data, you are in for some difficulty. To decode the above you need: 1) a base64 decoder, and 2) an asn1/der decoder. There are some internal NSS templates to do this (as least the der part). Of course if you can't allocate, non of the NSS decoders would work for you (The simplest requires NSPR arenas). Anyway the path forward is to do a base64 decode on the above data (you have to strip the ---- XXXXX----- portions yourself. The function you want is ATOB, so either ATOB_convertAsciiToItem or ATOB_AsciiToData() (defined in base64.h). Once you have the binary you want to decode the DER value. You can see some samples in mozilla/security/nss/lib/softoken/legacydb/keydb.c. The function seckey_decrypt_private_key is mostly what you want. You just need to skip the actual decrypt step. The public key function would be similiar, except you use a different template (and the key has fewer components). If you were operating from the proper NSS layer you could use PK11_ImportDERPrivateKeyInfoAndReturnKey() for the private key and SECKEY_DecodeDERPublicKey() for the public key (both still require ATOB_ first). bob </pre> Robert Relyea 2012-05-02T16:21:59 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16746 <pre>+2! On Sat, Apr 28, 2012 at 8:13 PM, Robert Townley &lt;fosscoder&lt; at &gt;gmail.com&gt; wrote: </pre> helpcrypto helpcrypto 2012-05-02T06:58:53 http://permalink.gmane.org/gmane.comp.mozilla.crypto/16745 <pre> On Tuesday, 1 May 2012 00:46:21 UTC+8, Robert Relyea wrote: Hi Bob, I'm extracting private interfaces for RSA functions compatible for our own VM, with our own instruction sets. Even, Dynamic memory allocation cannot work there. I've tested these low level functionality for RSA. Now, Is there a way to get the above keys - stripped and make it work in low level? Is it feasible? or I should consider doing something else? Thanks, Vejey </pre> VJ 2012-05-01T19:01:33 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.mozilla.crypto