Re: SSL Blacklist : List of servers using compromised private keys
On 01/23/2009 02:43 AM, Jan Schejbal: Hi, you can download all compromised keys by yourself. They are widely published. Has anyone actually published all (or "all interesting") weak private keys for SSL? I know such a release exists for SSH (which AFAIK uses a different exponent or something like that) and I know it is easily possible to compute at least a subset (at least architecture, key length and used PRNG variant seem to influence the key, so there are quite some sets of keys, not just 32k!) Is it a good idea to publish such key lists, or is it better to keep them unpublished so at least the script-kiddies cannot abuse them? Some of them can be found here: http://metasploit.com/users/hdm/tools/debian-openssl/ -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
Florian Weimer wrote: Perhaps Mozilla should change its policy to require CAs to revoke certs when the private key is known to be compromised, whether or not an attack is in evidence, as a condition of having trust bits in Firefox. I don't think this can be made a requirement. Sudden improvements in cryptanalysis are possible, and you don't want to turn that into an effective DoS attack on Internet users, do you? If the security of a root is compromised, I would expect its trust to removed, otherwise there is an illusion of security where in reality there is none. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
Hi, you can download all compromised keys by yourself. They are widely published. Has anyone actually published all (or "all interesting") weak private keys for SSL? I know such a release exists for SSH (which AFAIK uses a different exponent or something like that) and I know it is easily possible to compute at least a subset (at least architecture, key length and used PRNG variant seem to influence the key, so there are quite some sets of keys, not just 32k!) Is it a good idea to publish such key lists, or is it better to keep them unpublished so at least the script-kiddies cannot abuse them? Sincerely, Jan -- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention "FROM NG" in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers... -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: RSA Keygen problem
Julien R Pierre - Sun Microsystems wrote: Nelson, Nelson B Bolyard wrote: Julien R Pierre - Sun Microsystems wrote, On 2009-01-21 15:03: I don't like much the way that we implemented SSE2 on Linux - together in a single freebl shared library with the non-SSE2 version. That stands in the way of us implementing SSE2 in Solaris. See bug 458480 about that. Also bug 439199 about the Windows implementation. Most intel OS's don't mark their binaries based on any special instruction needs. Instead application pretty regularly use the logic "if SSE2 is available, do this, otherwise do that". There is no architectural problem with this on windows (Thanks for drawing my attention to the patch, I see nothing inherently wrong and believe we should pick it up!). It's solaris that has the weirdness, and is why we added the ability to load different binaries for different instruction set on the same platform. Please do not misconstrue something we did to support a particular platform as the "way it must be done" for all platforms. BTW, I don't have a problem with using that mechanism on Solaris, I do have a problem with forcing it on all other platforms which otherwise derive zero benefit from the cost of having to support multiple binaries and one is sufficient. I am not sure what's the best answer for Darwin. The Linux-like way is perfectly acceptable in Darwin. We have a proof of concept already. 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: RSA Keygen problem
On Jan 22, 6:46 pm, Nelson B Bolyard wrote: > > min: 389 ms, max: 2648 > > That's more like what's expected. > > > > > Is there a simple way to test if the generated values are correct ? > > Two ways come to mind. > > 1) Run NSS's cipher tests. > cd mozilla/security/nss/tests/cipher > cipher.sh > /tmp/cipher.sh.log 2>&1 > Then look at results.html in the generated directory > mozilla/tests_results/security/HOST.N > > 2) Run NSS's FIPS mode self test. > cd mozilla/security/nss/tests/fips > fips.sh > /tmp/fips.sh.log 2>&1 > Then look at results.html in the generated directory > mozilla/tests_results/security/HOST.N > > where HOST is your host name and N is an integer that increments with each > test run. Everything is green. The new asm file does not try to determine at runtime if SSE2 is present, but it does it at compile time. By default the Apple GCC version define __SSE2__, so the default is to use it on Mac. And as mention before, all supported Mac have a processor with SSE2 available, so it should be fine. Else, this is a simple copy/paste of the Linux version (without the .type lines, as the Darwin assembler does not like them). diff -Naur mozilla/security/nss/lib/freebl/Makefile mozilla/security/ nss/lib/freebl/Makefile --- mozilla/security/nss/lib/freebl/Makefile2008-03-28 01:35:26.0 +0100 +++ mozilla/security/nss/lib/freebl/Makefile2009-01-22 20:37:24.0 +0100 @@ -147,6 +147,27 @@ endif endif # Linux +ifeq ($(OS_TARGET),Darwin) +#ifeq ($(CPU_ARCH),x86_64) +#ASFILES = arcfour-amd64-gas.s mpi_amd64_gas.s +#ASFLAGS += -march=opteron -m64 -fPIC +#DEFINES += -DNSS_BEVAND_ARCFOUR -DMPI_AMD64 - DMP_ASSEMBLY_MULTIPLY +#DEFINES += -DNSS_USE_COMBA +#DEFINES += -DMP_CHAR_STORE_SLOW -DMP_IS_LITTLE_ENDIAN +# DEFINES += -DMPI_AMD64_ADD +#MPI_SRCS += mpi_amd64.c mp_comba.c +#endif +ifeq ($(CPU_ARCH),i386) +ASFILES = mpi_x86-darwin.s +DEFINES += -DMP_USE_UINT_DIGIT +DEFINES += -DMP_ASSEMBLY_MULTIPLY -DMP_ASSEMBLY_SQUARE +DEFINES += -DMP_ASSEMBLY_DIV_2DX1D +DEFINES += -DMP_CHAR_STORE_SLOW -DMP_IS_LITTLE_ENDIAN +# Should it be enabled on Darwin ? +#ECL_USE_FP = 1 +endif +endif # Darwin + ifeq ($(OS_TARGET),AIX) DEFINES += -DMP_USE_UINT_DIGIT ifndef USE_64 diff -Naur mozilla/security/nss/lib/freebl/mpi/mpi_x86-darwin.s mozilla/security/nss/lib/freebl/mpi/mpi_x86-darwin.s --- mozilla/security/nss/lib/freebl/mpi/mpi_x86-darwin.s1970-01-01 01:00:00.0 +0100 +++ mozilla/security/nss/lib/freebl/mpi/mpi_x86-darwin.s2009-01-22 22:41:36.0 +0100 @@ -0,0 +1,503 @@ +# +# * BEGIN LICENSE BLOCK * +# Version: MPL 1.1/GPL 2.0/LGPL 2.1 +# +# The contents of this file are subject to the Mozilla Public License Version +# 1.1 (the "License"); you may not use this file except in compliance with +# the License. You may obtain a copy of the License at +# http://www.mozilla.org/MPL/ +# +# Software distributed under the License is distributed on an "AS IS" basis, +# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License +# for the specific language governing rights and limitations under the +# License. +# +# The Original Code is the Netscape security libraries. +# +# The Initial Developer of the Original Code is +# Netscape Communications Corporation. +# Portions created by the Initial Developer are Copyright (C) 2000 +# the Initial Developer. All Rights Reserved. +# +# Contributor(s): +# +# Alternatively, the contents of this file may be used under the terms of +# either the GNU General Public License Version 2 or later (the "GPL"), or +# the GNU Lesser General Public License Version 2.1 or later (the "LGPL"), +# in which case the provisions of the GPL or the LGPL are applicable instead +# of those above. If you wish to allow use of your version of this file only +# under the terms of either the GPL or the LGPL, and not to allow others to +# use your version of this file under the terms of the MPL, indicate your +# decision by deleting the provisions above and replace them with the notice +# and other provisions required by the GPL or the LGPL. If you do not delete +# the provisions above, a recipient may use your version of this file under +# the terms of any one of the MPL, the GPL or the LGPL. +# +# * END LICENSE BLOCK * + +# $Id: mpi_x86.s,v 1.6 2006/12/11 09:45:32 gerv%gerv.net Exp $ +# + +.text + + # ebp - 36: caller's esi + # ebp - 32: caller's edi + # ebp - 28: + # ebp - 24: + # ebp - 20: + # ebp - 16: + # ebp - 12: + # ebp - 8: + # ebp - 4: + # ebp + 0: caller's ebp + # ebp + 4: return address + # ebp + 8: a argument + # ebp + 12: a_len argument + # ebp + 16: b argument + # ebp + 20: c argument + # registers: + # eax: + # ebx:carry + # ecx:a_len + # edx: + # esi:a ptr + # edi:c ptr +.private_extern_s_mpv_mul_d +_s_mpv_mul_d: +#ifndef __SSE2__ +push
Re: Take my database of certs/ssl details from high-traffic sites, please!
First off, Ian and Paul, glad you find it helpful, and thanks for the support. Let me know if there are things that would make it better. On 21-Jan-09, at 11:48 AM, Eddy Nigg wrote: I already left a message at the blog, but short notice here. This is certainly useful and even more, if we can reach more sites. Maybe allowing to query the DB directly could also be useful (instead of downloading 400 MB over the ocean). I only hope that your DB will not be misused by some certificate resellers ;-) It's certainly possible to add sites, though as I said in the post, it's not my aim to be exhaustive. I just want to be thorough enough to be able to draw meaningful conclusions from the data. I would love a way to query the data directly, do you know of such a front end, particularly for SQLite? If not, if you know of a generic DB-browsing front end for something like MySQL, I can look at porting a copy of the database over. Even with indices, querying the database can take tens of seconds, if not minutes, so it won't exactly be speedy; but it would be more accessible that way. Cheers, Johnathan --- Johnathan Nightingale Human Shield john...@mozilla.com -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
On Thu, Jan 22, 2009 at 6:05 AM, Ian G wrote: > On 22/1/09 13:54, Kyle Hamilton wrote: >> >> Ian, I'd rather not spell this out, because it's a blueprint that any >> malicious coder could follow. Unfortunately, you seem to insist on >> documentation -- and refuse to accept the word of those who actually >> do know. So. > > > Please Are you assuming here that we are the repository of all security > knowledge? Are you saying that the hackers don't know how to do these > spoofing attacks? Are we happy with a security-by-obscurity approach, and > it is too dangerous for people to really know what's going on? I've gotta > trust you? Because I don't know what I'm talking about, I should be scared? I'd suggest you drop the argumentum ad absurdum. This isn't what I'm stating, and you well know it. (or you should. If you don't, you really shouldn't be taking part in the conversation here.) Except, of course, the last: because you don't know what you're talking about, you SHOULD be scared. If you're really the one who wrote the financialcryptography site, you should know that all of the security is only as good as the primitives in use, and the assumptions inherent in their use. Two of which are: "keypairs are only as good as the entropy used to generate them" and "private keys must remain private". Without these assumptions, the security of the system isn't. The hackers do already know how to do this. That doesn't mean that I have to make it easier for people to do it without spending research time. And no, I'm not stating that we're the repository of all security knowledge. I'm simply stating that those of us who do know how to do it already know that the "clear and present danger" which you demand to know about does, truly, already exist. > It's an MITM, right? Is there any more to say about implementation that > changes that? The current thing we know about the MITM is that it can be > done via various spoofing tricks (DNS, BGP) from wherever. Considering that this is THE reason that TLS (along with server certificates, issued by a third party certifier and with private keys that are actually private) exists, I'd say it shows that the assumptions that allow TLS to be considered "secure" are completely violated in the case of use of poorly-generated random numbers as seeds for the RSA prime search. The "clear and present danger" comes in when you think about users who are using public wi-fi access points. The danger of spoofing was much less pronounced when users had to use wired connections, because they'd typically only use wired connections from hotels, workplaces, or their home cable/DSL -- and thus had more trust in the legal protections available because of money changing hands. > So the site's SSL communications can be MITM'd. Is that the conclusion? Not 'the site', but 'any site still using a weakly-generated key'. And not *can be*, but *have been*. (Or have you forgotten the case of the girl who accepted all the bogus certs because she thought that Firefox was screwing up? That wasn't quite as sophisticated an attack as I laid out, but if someone can do the bogus cert thing then they can just as easily extend it to be undetectable.) I respectfully suggest that you go back to auditing. That's really the only useful input that I've seen you make. (As it stands right now, your argument is essentially "since there's no liability, legally, nobody should bother trying to fix or shore up the current system, even when the underlying sanity-checks of the system are violated." The problem is, regardless of whether there's liability, THIS IS THE ONLY THING THAT THE USERS HAVE. If you want to design something better, do so, then propose it to the standards bodies.) -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DSV/S-TRUST root inclusion request
(sorry for the late response.) On Wed, Dec 17, 2008 at 4:20 AM, Ian G wrote: > On 17/12/08 12:42, Kyle Hamilton wrote: >> But... ... and would also violate the archival principle >> (that signatures of archived documents can be verified via the >> presence of a timestamp from a reputable timestamping authority and a >> trust anchor which still needs to be available). > > Yes, to recall an unpopular claim of mine: digital signing where it > attempts to mimic human signing should be deprecated in poorly architectured > applications like S/MIME. For reasons just like these. > > (BTW, where is this "archival principle" documented?) Aside from audits, it's also basically required by US Federal Court Rules of Civil Procedure 26 and 34, as effective 12/2006. Any court may require that any evidence submitted be authenticated. Without the root available to authenticate... Remember that it's not 'mimicing human signing'. It's preventing modification of what was originally sent. (It's rather like the process of committing logs -- if the logs need to be verifiable that nothing has been retroactively added or removed or changed, they need to have some means of chaining the IV from the prior log entry.) > It is perhaps fun to laugh about the silly Germans ... but consider: their > digital signature project is very serious, it is strongly supported by the > tax authorities and they fully intend for tax submissions to be signed. > They have already passed or attempted to pass the legislation to make this > so. > > Also, Germany is heartland for Mozilla. There are more supporters there > than other places, in general. That's because in the US, Firefox is coming to be viewed as an evil lesser than but akin to IE. -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: DSV/S-TRUST root inclusion request
On 12/17/2008 01:29 AM, Eddy Nigg: On 12/17/2008 01:26 AM, Frank Hecker: That's a good idea, I'll do that. I'd like to get a definitive answer on this question, since I know I've seen this practice with other CAs, including I think at least one not in Germany. Frank, I asked about it at the bug already earlier. Once I get the information I'll be glad to provide information about it, including translation about the important parts (if this suits us). I've received answers from the representative of S-Trust at the bug. As suspect right from the beginning, there is no such law or requirement as claimed initially that justifies the issuing of new roots every year for a life-time of only five years. For further reference see bug 370627 from comment 47 onwards: https://bugzilla.mozilla.org/show_bug.cgi?id=370627#c47 According to comments made by Nelson and others, I suggest to refrain from including this CA at this time. Their model is hardly sustainable, unnecessary complicated for no apparent benefit. Some of the documents I reviewed from the "Bundesnetzagentur" even explicitly discourages their implementation. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: RSA Keygen problem
Jean-Daniel wrote, On 2009-01-22 05:39: > Unfortunately it doesn't use gas. > > I have modified the mpi_x86.s to use be able to compile it using gcc, > but I have a question. Congratulations. You're well on your way to the fame and glory of becoming a contributor to NSS. :) Seriously, it sounds like you have the beginnings of a valuable contribution. > The darwin mpi library is configured to use 64bits mp_digit (as > ULONG_LONG_MAX is defined and long long are 64 bits), and so, the > assembly file does not works. > Now, if I use the MP_USE_UINT_DIGIT preprocessor flag, I can force it > to defined mp_digit as 32 bits value, and it compiles fine (using the > same sse2 assembly than linux). Yup, we define MP_USE_UINT_DIGIT on all x86_32 platforms where we use that assembler code in any of its various forms. > My first test shows a significant improvement: > > average: 1371 ms > min: 389 ms, max: 2648 That's more like what's expected. > > Is there a simple way to test if the generated values are correct ? Two ways come to mind. 1) Run NSS's cipher tests. cd mozilla/security/nss/tests/cipher cipher.sh > /tmp/cipher.sh.log 2>&1 Then look at results.html in the generated directory mozilla/tests_results/security/HOST.N 2) Run NSS's FIPS mode self test. cd mozilla/security/nss/tests/fips fips.sh > /tmp/fips.sh.log 2>&1 Then look at results.html in the generated directory mozilla/tests_results/security/HOST.N where HOST is your host name and N is an integer that increments with each test run. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
On 01/22/2009 01:45 AM, Nelson B Bolyard: Isn't the publishing of the private key enough evidence for compromise? At least it got us and some others to revoke all weak keys. IMO, yes, it is enough evidence. But the position of those CAs, as I understand it, is that such publication is only a potential compromise. Follow up on this one: The weak keys represent a suspected key compromise. Suspected key compromise allows for unilateral revocation by the CA usually. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Florian Weimer wrote: > What about requiring that all certificates must be published by the CA > (including sub-CAs)? No, this might lead to also revealing internal DNS names never meant to be public. Ciao, Michael. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
On 01/22/2009 03:56 PM, Ian G: LOL, this isn't a theoretical weakness, you can download all compromised keys by yourself. They are widely published. It's a theoretical weakness until you see evidence of damages. Ian, I'm somewhat tired arguing about this...but here is my take on this: Supposed you own a car which has the flaw that once in a while the engine explodes in a huge fireball. Now the vendor of the car knows about it and recalls all cars for a fix. Otherwise the car vendor would be liable to any damage their cars may so - specially since he is aware of the flaw. The public knows about the potential flaw by now already, and the owners of the car may have heard about it too. Failing to recall the cars and offering a fix might have consequences. Now compare this example to that of the weak keys. And here comes Ian and says, it's only a theoretical weakness until your car explodes and you've seen the evidence of damages. Well, boy, go ahead, drive your car (or weak keys) and thankfully you aren't running a CA. So in your eyes there would be no reason to disallow MD5 hashes either since no evidence of damage exists, right? The software vendors think apparently different about it and thankfully you aren't a browser vendor either... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
Julien R Pierre - Sun Microsystems wrote: > Paul Hoffman wrote: >> At 3:45 PM -0800 1/21/09, Nelson B Bolyard wrote: >>> Perhaps Mozilla should change its policy to require CAs to revoke certs >>> when the private key is known to be compromised, whether or not an >>> attack >>> is in evidence, as a condition of having trust bits in Firefox. >> >> Fully agree. > > Thirded. +1 > I'm surprised that isn't already the case :-( Me too. :-/ Ciao, Michael. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
On 22/1/09 00:45, Nelson B Bolyard wrote: Eddy Nigg wrote, On 2009-01-21 15:25: On 01/22/2009 01:07 AM, Nelson B Bolyard: Yes, but some of the CAs were emphatic that they would not revoke the certs unless their customers requested them to do so. As I understand it, basically they said that their agreement with their customer did not allow them to revoke the cert without the customer's permission, unless they were presented with evidence of an actual attack/compromise of the site whose cert was affected. I did not like that position, but they were adamant. Isn't the publishing of the private key enough evidence for compromise? At least it got us and some others to revoke all weak keys. IMO, yes, it is enough evidence. But the position of those CAs, as I understand it, is that such publication is only a potential compromise. lol... right. I had exactly this argument over at CAcert, when I said the old roots were compromised because there was no doco or history that said that they were secure [1]. They said "compromised == evidence of breach" and I said "compromised == no evidence of security." Semantics matter a lot. Does anyone have a definition of the word "compromise" ? They require evidence that the published key is actually being used to attack the site. Otherwise, their customer agreement does not let them revoke the certs. I don't think that's an honorable position for a CA to be in, but that's just my opinion. I can see their point of view, it does rather strike me as a question about business, not anything else. They are taking on the liability (aren't they?) for that site, so why can't they run the risk? That's what the contracts are for, no? Or is your point that you don't trust the contracts? iang [1] this is a published squabble, somewhere or other, and was resolved in 2007 by a board decision to make new roots. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
On 22/1/09 13:54, Kyle Hamilton wrote: Ian, I'd rather not spell this out, because it's a blueprint that any malicious coder could follow. Unfortunately, you seem to insist on documentation -- and refuse to accept the word of those who actually do know. So. Please Are you assuming here that we are the repository of all security knowledge? Are you saying that the hackers don't know how to do these spoofing attacks? Are we happy with a security-by-obscurity approach, and it is too dangerous for people to really know what's going on? I've gotta trust you? Because I don't know what I'm talking about, I should be scared? It's an MITM, right? Is there any more to say about implementation that changes that? The current thing we know about the MITM is that it can be done via various spoofing tricks (DNS, BGP) from wherever. So the site's SSL communications can be MITM'd. Is that the conclusion? iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
On 22/1/09 13:41, Eddy Nigg wrote: On 01/22/2009 02:26 PM, Ian G: Theoretical weaknesses in crypto mean little, it's a business discussion, and the threat has to be related to the business risks, liabilities and obligations. LOL, this isn't a theoretical weakness, you can download all compromised keys by yourself. They are widely published. It's a theoretical weakness until you see evidence of damages. You can also purchase most of america's credit cards for not many $$$. This is a theoretical weakness in the PKI because you can find the one you want for the identity you want. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: RSA Keygen problem
On Jan 22, 1:23 am, Robert Relyea wrote: > Nelson B Bolyard wrote: > > Julien R Pierre - Sun Microsystems wrote, On 2009-01-21 15:03: > > >> Even if you end up building NSS with optimizations, they use the regular > >> multiply instructions, which performs best on AMD chips, but not as well > >> on Intel CPUs. For Intel, one needs to use the SSE2 and above > >> instructions set, which NSS currently doesn't do - except on one > >> platform, Linux. > > > Is there any reason why we can't use the same optimizations on Darwin/x86 > > as we use on Linux? > > If darwin/x86 uses gas, then it's should be just a matter of setting > some defines in the freebl make file and testing. (the primary thing > that holds back using these assembler optimizations is differences in > the assembler syntax on our various platforms). > Unfortunately it doesn't use gas. I have modified the mpi_x86.s to use be able to compile it using gcc, but I have a question. The darwin mpi library is configured to use 64bits mp_digit (as ULONG_LONG_MAX is defined and long long are 64 bits), and so, the assembly file does not works. Now, if I use the MP_USE_UINT_DIGIT preprocessor flag, I can force it to defined mp_digit as 32 bits value, and it compiles fine (using the same sse2 assembly than linux). My first test shows a significant improvement: average: 1371 ms min: 389 ms, max: 2648 Is there a simple way to test if the generated values are correct ? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
Ian, I'd rather not spell this out, because it's a blueprint that any
malicious coder could follow. Unfortunately, you seem to insist on
documentation -- and refuse to accept the word of those who actually
do know. So.
The "clear and present danger" exists.
It requires:
A router (say, a WRT54G) running a custom distribution of Linux,
listening on all 10.0.0.0/8 addresses.
A DHCP configuration that provides a local DNS server configuration.
A custom DNS server ('custom' in that it answers all name lookups with
10.0.0.0/8 addresses, allocating them dynamically)
A webserver that's tightly integrated with the DNS server (so it knows
the names that have been looked up and the IPs that they have been
given).
All the compromised keys.
Logic in the webserver to automatically download the certificate of
any site, and to recognize the compromised keys.
If it's not a weak key, transparently proxy the connection.
If it is a weak key, the webserver loads up the key for it along with
the certificate, then acts as the TLS endpoint in MITM mode,
decrypting the connection and talking to the real server as a TLS
client.
Since the name matches the certificate, even if it's not the True
World-Accessible IP for the server, Firefox won't complain.
-Kyle H
On Thu, Jan 22, 2009 at 4:26 AM, Ian G wrote:
> On 22/1/09 12:26, Eddy Nigg wrote:
>>
>> On 01/22/2009 01:13 PM, Ian G:
>>>
>>> Although it is good that people rose to the challenge of the debian PRNG
>>> failure, I do not understand the position that all certs had to be
>>> revoked. Isn't it a situation between the Subscribers, Relying Parties
>>> and the CA concerned? That is, notification is as far as you can go?
>>
>> Indeed! Mozilla is a relying party.
>
>
> good point. So this means that Mozilla has agreed to the RPA?
>
> ;-) The problem with acting "as if" is that you get all the
> responsibilities and none of the powers.
>
>
>> A weak key is compromised from the outset and upon detection (which can
>> be actively pursued) requires revocation of the key by the CA. This is
>> what most CAs have in their policies. This was what drove some CAs to
>> actually revoke them. Gerv and others were very helpful in pointing out
>> the arguments in favor of such an action.
>
>
> Arguments in favour ... are nice. What about arguments against?
>
> The system could be further protected by other means. It could be used for
> client-cert work. It could be in use for a low-security usage, such as
> would be acceptable for SSCs. It could be an old or deprecated site. It
> could be a no-liability cert (that's an oxymoron, all certs are
> no-liability, but oh well)... It could be an expiry in a month. It could
> be a free cert, in which case no support is offered? It could be an S/MIME
> cert for internal email, in which case who cares? There could be penalties
> for revocation. The subscriber agreement could have covered this already.
>
> Unless you can demonstrate a clear and present danger to the end-user of
> Mozilla's products, it may be hard to to establish a line here. Theoretical
> weaknesses in crypto mean little, it's a business discussion, and the threat
> has to be related to the business risks, liabilities and obligations.
>
>
>
> iang
> --
> 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: SSL Blacklist : List of servers using compromised private keys
On 01/22/2009 02:26 PM, Ian G: Theoretical weaknesses in crypto mean little, it's a business discussion, and the threat has to be related to the business risks, liabilities and obligations. LOL, this isn't a theoretical weakness, you can download all compromised keys by yourself. They are widely published. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
On 22/1/09 12:26, Eddy Nigg wrote: On 01/22/2009 01:13 PM, Ian G: Although it is good that people rose to the challenge of the debian PRNG failure, I do not understand the position that all certs had to be revoked. Isn't it a situation between the Subscribers, Relying Parties and the CA concerned? That is, notification is as far as you can go? Indeed! Mozilla is a relying party. good point. So this means that Mozilla has agreed to the RPA? ;-) The problem with acting "as if" is that you get all the responsibilities and none of the powers. A weak key is compromised from the outset and upon detection (which can be actively pursued) requires revocation of the key by the CA. This is what most CAs have in their policies. This was what drove some CAs to actually revoke them. Gerv and others were very helpful in pointing out the arguments in favor of such an action. Arguments in favour ... are nice. What about arguments against? The system could be further protected by other means. It could be used for client-cert work. It could be in use for a low-security usage, such as would be acceptable for SSCs. It could be an old or deprecated site. It could be a no-liability cert (that's an oxymoron, all certs are no-liability, but oh well)... It could be an expiry in a month. It could be a free cert, in which case no support is offered? It could be an S/MIME cert for internal email, in which case who cares? There could be penalties for revocation. The subscriber agreement could have covered this already. Unless you can demonstrate a clear and present danger to the end-user of Mozilla's products, it may be hard to to establish a line here. Theoretical weaknesses in crypto mean little, it's a business discussion, and the threat has to be related to the business risks, liabilities and obligations. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
Not really, Ian. Basically, MITM attacks against the sites involved are now trivial, and we already know that MITM attacks are being mounted by unscrupulous operators of unencrypted wireless access points. All the attacker must do at this point is download the certificates from the affected sites, and they can authenticate as those sites without triggering any warning. This is an issue that affects the entire PKI. If any site uses a weak key and the CA hasn't revoked the cert, then that site can be spoofed without warning. -Kyle H On Thu, Jan 22, 2009 at 3:13 AM, Ian G wrote: > > Although it is good that people rose to the challenge of the debian PRNG > failure, I do not understand the position that all certs had to be revoked. > Isn't it a situation between the Subscribers, Relying Parties and the CA > concerned? That is, notification is as far as you can go? > > As a sort of odd anecdote, one person of some rather excellent crypto and > PKI knowledge over at CAcert insisted that he be allowed to be able to > publish his private key for some arcane crypto experiment. As far as I > know, he didn't get a positive answer on that point ... but it does rather > make one think about the limits of the process. > > iang > -- > 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: SSL Blacklist : List of servers using compromised private keys
On 01/22/2009 01:13 PM, Ian G: Although it is good that people rose to the challenge of the debian PRNG failure, I do not understand the position that all certs had to be revoked. Isn't it a situation between the Subscribers, Relying Parties and the CA concerned? That is, notification is as far as you can go? Indeed! Mozilla is a relying party. A weak key is compromised from the outset and upon detection (which can be actively pursued) requires revocation of the key by the CA. This is what most CAs have in their policies. This was what drove some CAs to actually revoke them. Gerv and others were very helpful in pointing out the arguments in favor of such an action. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
On 22/1/09 00:07, Nelson B Bolyard wrote: Jean-Marc Desperrier wrote, On 2009-01-21 01:13 PST: Now did we not receive promises by the CAs that they were *actively* working to solve the problem and get all sites to replace their cert ? Yes, but some of the CAs were emphatic that they would not revoke the certs unless their customers requested them to do so. As I understand it, basically they said that their agreement with their customer did not allow them to revoke the cert without the customer's permission, unless they were presented with evidence of an actual attack/compromise of the site whose cert was affected. I did not like that position, but they were adamant. Although it is good that people rose to the challenge of the debian PRNG failure, I do not understand the position that all certs had to be revoked. Isn't it a situation between the Subscribers, Relying Parties and the CA concerned? That is, notification is as far as you can go? As a sort of odd anecdote, one person of some rather excellent crypto and PKI knowledge over at CAcert insisted that he be allowed to be able to publish his private key for some arcane crypto experiment. As far as I know, he didn't get a positive answer on that point ... but it does rather make one think about the limits of the process. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 01/22/2009 12:17 PM, Kyle Hamilton: - The ability for other entities to mine that data for improper contact - The ability for the information in the certificates to be otherwise misused - Not every certificate user wants to identify as being a part of a given PKI system - Requiring full disclosure of the linkage of legal name to email address (for end-user certs, not necessarily end-entity certs) violates the end-entity's ability to control dissemination of information * nobody has yet signed up for this * if this becomes common, it'll be the death knell for client certificate authentication (nobody will participate) - No CA wants to reveal its actual subscriber numbers I'm pretty sure that Eddy'll be able to come up with more, as well as Rob, and representatives from other CAs. I think you covered it even better than me :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 01/22/2009 11:59 AM, Florian Weimer:
http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt
The list doesn't include sub-CAs, which are equivalent to listed CAs
for all practical purposes.
Well, if you ping a web site then you'll most likely also know the
issuer and ultimately the CA root. Scripts can do that too...
...but since CAs know to whom they issued certificates and have the
certificates themselves, it's very easy for them to find the compromised
keys.
It's also difficult to match the blobs to
legal entities ("Equifax" comes to my mind).
I agree, but this is a different matter really.
No it's quite easy to do that.
For Mozilla? How so?
A certificate always has to chain to a valid root, otherwise the
certificate isn't viewed at as valid (by Mozilla software anyway).
Transparency. You can actually check what's in those CRLs and what
kind of mistakes are being covered up.
Well, there is apparently a problem publishing end-user details so
bluntly as also a recent incident has shown. Not that it's impossible to
obtain the certificates for many sites as Johnathan demonstrated with
his robot and as a certain reseller of certificates did that as well.
But I agree that it would however be interesting to review such a list
and compare to the published CRLs :-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog: https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On Thu, Jan 22, 2009 at 1:59 AM, Florian Weimer wrote: > * Eddy Nigg: >> but I guess that sub CAs could be published, end-user certificates >> most likely not. > > Why not? Among other things: - The ability for other entities to mine that data for improper contact - The ability for the information in the certificates to be otherwise misused - Not every certificate user wants to identify as being a part of a given PKI system - Requiring full disclosure of the linkage of legal name to email address (for end-user certs, not necessarily end-entity certs) violates the end-entity's ability to control dissemination of information * nobody has yet signed up for this * if this becomes common, it'll be the death knell for client certificate authentication (nobody will participate) - No CA wants to reveal its actual subscriber numbers I'm pretty sure that Eddy'll be able to come up with more, as well as Rob, and representatives from other CAs. -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
* Eddy Nigg:
> On 01/22/2009 11:04 AM, Florian Weimer:
>> * Eddy Nigg:
>>
>>> As a matter of fact, most CAs have policies in place which require
>>> them upon knowledge of potential or *suspected* compromise to revoke
>>> ANY certificate. I'm certain those policies exist for the top CAs
>>> covering the majority of certificates. The keys are compromised, not
>>> only suspected to be compromised. It's known which keys and
>>> certificates are affected (by the CAs themselves).
>>
>> Yes, but we don't know all the CAs that exist and are recognized by
>> Mozilla. 8-(
>
> Of course we know. It's right here:
> http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt
The list doesn't include sub-CAs, which are equivalent to listed CAs
for all practical purposes. It's also difficult to match the blobs to
legal entities ("Equifax" comes to my mind).
>> If you've got a sub-CA under a browser-listed root CA, it's kind of
>> hard for Mozilla or the root CA to enforce any rules (let alone detect
>> violations).
>
> No it's quite easy to do that.
For Mozilla? How so?
>> What about requiring that all certificates must be published by the CA
>> (including sub-CAs)?
>
> I don't know the benefit for it,
Transparency. You can actually check what's in those CRLs and what
kind of mistakes are being covered up.
> but I guess that sub CAs could be published, end-user certificates
> most likely not.
Why not?
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
On 01/22/2009 11:04 AM, Florian Weimer: * Eddy Nigg: As a matter of fact, most CAs have policies in place which require them upon knowledge of potential or *suspected* compromise to revoke ANY certificate. I'm certain those policies exist for the top CAs covering the majority of certificates. The keys are compromised, not only suspected to be compromised. It's known which keys and certificates are affected (by the CAs themselves). Yes, but we don't know all the CAs that exist and are recognized by Mozilla. 8-( Of course we know. It's right here: http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt If you've got a sub-CA under a browser-listed root CA, it's kind of hard for Mozilla or the root CA to enforce any rules (let alone detect violations). No it's quite easy to do that. What about requiring that all certificates must be published by the CA (including sub-CAs)? I don't know the benefit for it, but I guess that sub CAs could be published, end-user certificates most likely not. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL Blacklist : List of servers using compromised private keys
On 01/22/2009 08:53 AM, Florian Weimer: * Nelson B. Bolyard: IMO, yes, it is enough evidence. But the position of those CAs, as I understand it, is that such publication is only a potential compromise. They require evidence that the published key is actually being used to attack the site. Otherwise, their customer agreement does not let them revoke the certs. I don't think that's an honorable position for a CA to be in, but that's just my opinion. It's more like the CA policies preventing obtaining customer private keys, so they can't check at all. CAs have all the potentially used keys already. CAs can easily find the affected certificates and some CAs found and revoked all certificates with weak keys in order to protect the relying parties and subscribers. CAs don't need to obtain the private keys from their customers. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Policy: revoke on private key exposure
* Eddy Nigg: > As a matter of fact, most CAs have policies in place which require > them upon knowledge of potential or *suspected* compromise to revoke > ANY certificate. I'm certain those policies exist for the top CAs > covering the majority of certificates. The keys are compromised, not > only suspected to be compromised. It's known which keys and > certificates are affected (by the CAs themselves). Yes, but we don't know all the CAs that exist and are recognized by Mozilla. 8-( If you've got a sub-CA under a browser-listed root CA, it's kind of hard for Mozilla or the root CA to enforce any rules (let alone detect violations). What about requiring that all certificates must be published by the CA (including sub-CAs)? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: RSA Keygen problem
On Jan 22, 2:48 am, Julien R Pierre - Sun Microsystems wrote: > Jean-Daniel, > > Jean-Daniel wrote: > >> Another possible reason is if you are comparing 32-bit NSS vs 64-bit > >> OpenSSL binaries. Regardless of assembly optimizations. The 64-bit code > >> is always a lot faster, even without optimizations. > > > Of course, but as my test exec is link on both library, so that could > > no be the case. > > Anyway by default, gcc produce 32 bits binary on OS X, and you should > > ask it explicitly to get a 64 bits version (and I don't ask it). > > I am not sure what kind of application you are developing, but if RSA > keygen performance is an issue, I would strongly recommend you consider > going 64-bits if it's an option. > > > That's what I supected. > > > If I do not managed to find a way to generate an optimized binary, I > > think I'm going to workaround this issue by generating the key using > > OpenSSL and then, import them in my NSS db. > > I am not sure if we have the required functions to import raw private > keys in the NSS API. We go out of our way to make it difficult and > ensure that never happens :-). Even if you can do it, it will be difficult. In fact, I do not directly use the OpenSSL generator, I'm using the CDSA keygen API and it return a PKCS1 public key and a PKCS8 private key. After that, I can decode the public key using SEC_ASN1DecodeItem with the SECKEY_RSAPublicKeyTemplate and I can use PK11_ImportDERPrivateKeyInfoAndReturnKey() to import the private key. Except if there is know bugs with this function ? > I would suggest you open an RFE in bugzilla against NSS to add freebl > optimizations on Darwin . I will have a look at that too. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
