Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 2010/10/29 01:44 PDT, Nelson B Bolyard wrote: No, passwords simply have NO PLACE in protecting the average user from phishing. And it doesn't matter whether the password is used to derive a session encryption key, or just as an authentication token. The user is just as vulnerable either way. Illustrative case history: http://imgur.com/cNorB -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 2010/10/28 03:12 PDT, Jean-Marc Desperrier wrote: Nelson B Bolyard wrote: [...] It because none of them: J-PAKE, SPEKE, SRP, or for that matter, good old CRAM-MD5 address the NUMBER ONE problem with passwords. PHISHING. They are a very significant progress with regard to that actually. What do JPAKE, SPEKE and SRP claim to give you that CRAM-MD5 does not? ZERO-KNOWLEDGE That's resistance to something other than phishing. That's dealing with an untrustworthy peer, with whom you WANT to trust, to the point that you do give that party an authenticator of some sort. That's NOT the big problem. The server can not attack by brute-force the content of the exchange to deduce what you password is. Right, so the attacker just asks you for it, very convincingly. Now, that's not it : What they truly bring is that if you are misled into making an handshake with a phishing site, you don't give to that site any information about what your password might be. Sorry, untrue. The attacker puts up a password dialog. You type your password into it. You give away your password. Maybe YOU (JMD) don't, but then, you (JMD) aren't the typical phishing victim. You have a good idea what to look out for. The phishing victim does not, and so enters his password anywhere that asks, because he cannot (or will not) distinguish between the places where he should and those where he shouldn't. If you are tricked into making the handshake with the wrong site, there's no bad consequence. Right. That attack is not to get you to HANDSHAKE with the wrong site. It's to get you to connect to the wrong site that ASKS YOU TO ENTER YOUR PASSWORD. So the risk is to be tricked into entering your password inside a field that doesn't do a handshake, but instead just sends copy of it to the pirate. Right. Therefore password exchange solution that relies on you entering the password inside a standard web page are still strongly vulnerable to the phishing problem, and there's no progress over older password schemes. Right. But if the password is entered inside an element that is unambiguously the GUI of your browser, web site can not do a phishing attack against it any more, and the solution is actually quite good. ... ASSUMING that the user is bright enough to understand the difference between chrome and non-chrome, and which one is trustworthy ... but years of experience have shown us that most users are not. For years, and to this very day, web sites put lock icons in the pages to try to convince the users that the page is secure. My own bank does it! MOST users still have no clue about trust of chrome vs trust of web page content. Not a clue. I had a bank account executive sit in front of a browser once, and instruct me in how to use the browser to do on-line banking. I sat through his presentation (despite having been a user of online banking for over a decade by then) to see how well HE understood it. He informed me that he was specially trained by his bank to train customers in how to lower their risk of being swindled. The FIRST THING he told me was to look for the lock icon in the web page content to be sure I was looking at a secure page, before typing in my bank password. I asked him what was the difference between that lock icon and the one down in the corner of the window, against the background that matched the window border (he was using MSIE). He had never noticed that lower icon before, and had no idea what it meant. So much for his special training. No, passwords simply have NO PLACE in protecting the average user from phishing. And it doesn't matter whether the password is used to derive a session encryption key, or just as an authentication token. The user is just as vulnerable either way. A password user's best protection against attack is simply appearing to be a low-value target. There are so many of them waiting to be attacked that the trick is to appear to be less worth attacking than one of the millions of others. Therefore the actual gap in security between the two is : - A : An attaquer that find a way to create a windows that tricks users to believe it's the genuine Firefox GUI for the password, without having to use chrome privilege. No need to convince the user that it's genuine Firefox GUI because the user has no idea what the significance of that is. Any ordinary web page with a password field in the page content will suffice. - B : An attaquer that uses the usual weaknesses of passwords to get access without phishing the user. Those usual weaknesses being that passwords are frequently very weak, but the worst I believe is that users frequently reuse them. So the attacker could obtain the value of the password of the user at another site, and use it to guess accurately what he's using at the protected site. Yup. That's another reason why you don't want the
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 10/29/2010 03:44 AM, Nelson B Bolyard wrote: On 2010/10/28 03:12 PDT, Jean-Marc Desperrier wrote: Nelson B Bolyard wrote: [...] It because none of them: J-PAKE, SPEKE, SRP, or for that matter, good old CRAM-MD5 address the NUMBER ONE problem with passwords. PHISHING. They are a very significant progress with regard to that actually. What do JPAKE, SPEKE and SRP claim to give you that CRAM-MD5 does not? ZERO-KNOWLEDGE That's resistance to something other than phishing. That's dealing with an untrustworthy peer, with whom you WANT to trust, to the point that you do give that party an authenticator of some sort. If I understand it correctly, one thing it does do is convert an offline password cracking attack into an active real-time MitM. The attacker is required to use the session right then, he can not harvest the login credentials for later use. Now, the extent to which this represents a real improvement in the effective security of the average user is a very open question. I think that in practice, fewer attackers have demonstrated an online attack capability (e.g. Zeus) than have using simple password harvesting. But if somehow they ran out of usable password credentials to steal, they'd probably become more sophisticated. That's NOT the big problem. [...] Right, so the attacker just asks you for it, very convincingly. The attacker puts up a password dialog. You type your password into it. You give away your password. ... ASSUMING that the user is bright enough to understand the difference between chrome and non-chrome, and which one is trustworthy ... but years of experience have shown us that most users are not. It's impossible to discuss security unless we're able to expect some minimal degree of competence on the part of the user. This applies to telephone and mail scams just as much as data security. Instead of the chrome/nonchrome lock icon distinction, we could equally say that typical users are willing to download and install executables, at which all bets are off. I've even heard of a (non-US) bank that required users to do exactly that in order to access its site! Whether or not Firefox can make an effective UI for this kind of security is an altogether different question. My guess is that if Mozilla doesn't do the best possible job of it with Firefox, extension developers and/or Google Chrome will. For years, and to this very day, web sites put lock icons in the pages to try to convince the users that the page is secure. They may be in part reacting to users' expectations of lock icons. Or graphic designers simply like to decorate the page with little logos. My own bank does it! MOST users still have no clue about trust of chrome vs trust of web page content. Not a clue. Just a personal anecdote, I find the color changes in the address bar to be a good visual indicator. The red background really stands out when you're used to seeing blue there. I had a bank account executive sit in front of a browser once, and instruct me in how to use the browser to do on-line banking. I sat through his presentation (despite having been a user of online banking for over a decade by then) to see how well HE understood it. He informed me that he was specially trained by his bank to train customers in how to lower their risk of being swindled. The FIRST THING he told me was to look for the lock icon in the web page content to be sure I was looking at a secure page, before typing in my bank password. I asked him what was the difference between that lock icon and the one down in the corner of the window, against the background that matched the window border (he was using MSIE). He had never noticed that lower icon before, and had no idea what it meant. So much for his special training. Classic! No, passwords simply have NO PLACE in protecting the average user from phishing. And it doesn't matter whether the password is used to derive a session encryption key, or just as an authentication token. The user is just as vulnerable either way. Even myself, whom I consider pretty paranoid about these things, occasionally enter the right password (for one system) into the wrong password field. A password user's best protection against attack is simply appearing to be a low-value target. There are so many of them waiting to be attacked that the trick is to appear to be less worth attacking than one of the millions of others. Which only works if you don't have enough to lose to make you worth of a targeted attack. Hardware protected private keys have a much more significant added value than software ones when compared to those schemes. Unfortunately they are still very little used. Except in China, surprisingly (Banks there have distributed millions of PKI hardware token to identify on their web sites) Yeah, the Russian banks all do this, too. Why can't the bankers in the free world have as much of a clue about network security as those
Re: J-PAKE (was Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync)
Jean-Marc Desperrier wrote: The reference I gave before shows that there is now a widely accepted opinion that SRP does not infringe on patent more than J-PAKE (even if there was indeed that doubt a few years ago). A patent that covers SRP might be found, but it does not appear today to be more likely than it is for J-PAKE. It is hard for most of the people on the mailing list to participate in a meaningful discussion of patents for a variety of reasons, so I'm just going to focus on the technical reasons for implementing J-PAKE instead of SRP. Balanced vs augmented does not matter for Sync's usage because the user is at both end points. If you don't need augmented security, J-PAKE makes more sense. Actually, what I wrote above isn't correct. A balanced scheme is actually better for Sync because we are asking the user to read a code from the screen of device 1 and type it into device 2. Both devices need the same psssword/PIN. I'm now reading here http://www.mail-archive.com/cryptogra...@metzdowd.com/msg09739.html that J-PAKE is *proven* to be no weaker than the algorithms it relies on. I am very interested in hearing what people think about the validity of the proofs in the J-PAKE paper and whether any security considerations have been overlooked. FWIW, I am pretty sure that we will be having a discussion about SRP and other solutions to the problems that SRP solves when we do planning for post-FF4 releases. Implementing J-PAKE now for this one Sync use case doesn't mean that we will prefer J-PAKE for solving those other problems, and it doesn't mean that we've decided to avoid implementing SRP. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
Nelson B Bolyard wrote: [...] I'm talking about putting JBAKE (or whatever it is) into the base product. [...] Is there something specific about J-PAKE that you think is bad or worse than some alternative? Are you objecting to J-PAKE because you do not trust the proofs of security given by the authors? Is there anything you'd like to have clarified about how the Sync team is proposing to use J-PAKE and what steps we're planning to take to make the key exchange safe? Thanks, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
Brian Smith wrote: Nelson B Bolyard wrote: [...] I'm talking about putting JBAKE (or whatever it is) into the base product. [...] Is there something specific about J-PAKE that you think is bad or worse than some alternative? Are you objecting to J-PAKE because you do not trust the proofs of security given by the authors? Is there anything you'd like to have clarified about how the Sync team is proposing to use J-PAKE and what steps we're planning to take to make the key exchange safe? Hi, Brian. I believe mostly the problem is that the enthousiam level of Nelson for any password based solution is extremly low. I think the best way forward for now is to work to make FreeBL/mpi available for javascript, use it for your J-PAKE implementation, but include a way to select the algorithm in your protocol so that it's not hardcoded to be J-PAKE. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: J-PAKE (was Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync)
Brian Smith wrote: A balanced scheme is actually better for Sync because we are asking the user to read a code from the screen of device 1 and type it into device 2. Both devices need the same psssword/PIN. The augmented scheme of SRP can be degraded to a balanced scheme if you need. It's trivial to regenerate the verifier from the password when needed, instead of just getting it out of the storage. I am very interested in hearing what people think about the validity of the proofs in the J-PAKE paper and whether any security considerations have been overlooked. IMO the trouble with J-PAKE is that it's probably an order of magnitude or more less used than SRP. It means less eyes on it to see the defaults, and that in princip is a problem. I've found the initial proof of security for SRP : http://srp.stanford.edu/ndss.html#SECTION0004 That's the v3 version of 1997. While the proofs have not been repudiated, some minor problems have been found and the v6 version has been issued to solve them as described here : http://srp.stanford.edu/srp6.ps FWIW, I am pretty sure that we will be having a discussion about SRP and other solutions to the problems that SRP solves when we do planning for post-FF4 releases. Implementing J-PAKE now for this one Sync use case doesn't mean that we will prefer J-PAKE for solving those other problems, and it doesn't mean that we've decided to avoid implementing SRP. I think it would be dead-code to have an implementation for both. By versionning the protocol, you can go with J-PAKE now, and use only SRP later. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 22/10/2010 19:07, Brian Smith wrote: Speaking only for myself, I have no objection to offering the mp_int bignum API as a public API out of freebl3. If people are open to having the J-PAKE building blocks in FreeBL, then we wouldn't need MPI to be part of the public API. The main concern with putting J-PAKE building blocks in NSS is getting that NSS release out for FF4.0. The MPI option is not a bad option, having an efficient bignums implementation available would probably be useful for several people. You want it exported so you can call from js-ctypes ? In fact, making this library and bignums available to all javascript would be useful. Brendan happens to be currently thinking about it http://brendaneich.com/2010/10/should-js-have-bignums/ but it certainly won't happen soon. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: J-PAKE (was Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync)
Brian Smith wrote: Jean-Marc Desperrier wrote: Why are you choosing J-PAKE instead of SRP ? The J-PAKE authors claim they developed J-PAKE to avoid patents that cover other algorithms, and they claim they won't patent it. I don't know if either claim is true or not. The reference I gave before shows that there is now a widely accepted opinion that SRP does not infringe on patent more than J-PAKE (even if there was indeed that doubt a few years ago). A patent that covers SRP might be found, but it does not appear today to be more likely than it is for J-PAKE. [...] Balanced vs augmented does not matter for Sync's usage because the user is at both end points. The end-user is establishing a secure channel from one of his/her devices to another one of his/her devices that are in the same location. Also, there is a new PIN (password) for every transaction. See https://wiki.mozilla.org/Services/Sync/SyncKey/J-PAKE If you don't need augmented security, J-PAKE makes more sense. I'm now reading here http://www.mail-archive.com/cryptogra...@metzdowd.com/msg09739.html that J-PAKE is *proven* to be no weaker than the algorithms it relies on. I don't know have exact references but I doubt that version 6 of SRP doesn't have an equivalent security proof, given the number of standards that rely on it. Wikipedia says even if one or two of the cryptographic primitives it uses are attacked, it is still secure but doesn't give a direct link that shows that (they are reference to it resisting to collision attacks on SHA1). Given the number of protocols that include SRP (SSL/TLS, EAP, SAML), given that there's already a proposed patch for NSS (bug 405155, bug 356855), a proposed patch for openssl ( http://rt.openssl.org/Ticket/Display.html?id=1794user=guestpass=guest ), I still think SRP is the better choice since the effort to implement it would be much more widely useful than with J-PAKE. On the long term, I wouldn't be surprised if at some point you'll add another scenario where augmented security would be useful, and you will in all likehood stay the only users of J-PAKE, I believe SRP will certainly end up being included, and it will be a little stupid to have 2 functionally equivalent algorithms. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On Oct 21, 7:58 pm, Robert Relyea rrel...@redhat.com wrote: SHA1Context SHA1_Hash SHA1_HashBuf SHA1_NewContext SHA1_DestroyContext SHA1_Begin SHA1_Update SHA1_End The exported equivalence to these functions are: #include sechash.h I see. Having found the SHA1_* functions in blapi.h I assumed they were exported, too. It depends on what J-PAKE is doing. My guess is it's doing a zero knowledge proof algorithm (given the need for add and sub), which is generally useful. Yes, J-PAKE uses zero knowledge proofs. mpi is used to do those as well as compute the key that both sides agree upon. I would be view a patch that puts the zero knowledge proof into freebl with favor (and would clear out time to review such a patch). Not sure how generic the signature of the zero knowledge proof we use in J-PAKE is. Compatibility with the implementation found in OpenSSL is important for us right now (the Firefox Home app for the iPhone uses OpenSSL). It hashes things in a particular way to avoid moving goalposts attacks. See http://www.links.org/?p=393. As Brian points out, pushing the J-PAKE implementation down to NSS may have several advantages. This might include building blocks in freebl or not. For Firefox Sync we'd just need a public API that we can use going forward. I for one would feel more comfortable with this officially being in NSS. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
Philipp von Weitershausen wrote: Not sure how generic the signature of the zero knowledge proof we use in J-PAKE is. Compatibility with the implementation found in OpenSSL is important for us right now Hi, Why are you choosing J-PAKE instead of SRP ? Looking for an assessment of J-PAKE against SRP, I found the following that make me worried that choice's a mistake. http://rdist.root.org/2010/09/08/clench-is-inferior-to-tlssrp/#comment-5990 The JPAKE in OpenSSH is unfinished and I don’t recommend enabling it [...] When writing it, I came up with a hacky solution to the cleartext password storage problem [...] http://rdist.root.org/2010/09/08/clench-is-inferior-to-tlssrp/#comment-5993 “Balanced” is symmetric and requires both sides to hold the same authenticator (e.g., a plaintext password). “Augmented” has the additional property that compromise of the server does not yield the key necessary to impersonate the client JPAKE and SPEKE are balanced schemes and thus have the same problem as Clench. However, SRP does not. SRP is an augmented scheme -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
J-PAKE (was Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync)
Jean-Marc Desperrier wrote: Why are you choosing J-PAKE instead of SRP ? The J-PAKE authors claim they developed J-PAKE to avoid patents that cover other algorithms, and they claim they won't patent it. I don't know if either claim is true or not. http://rdist.root.org/2010/09/08/clench-is-inferior-to-tlssrp/#comment-5993 JPAKE and SPEKE are balanced schemes and thus have the same problem as Clench. However, SRP does not. SRP is an augmented scheme Balanced vs augmented does not matter for Sync's usage because the user is at both end points. The end-user is establishing a secure channel from one of his/her devices to another one of his/her devices that are in the same location. Also, there is a new PIN (password) for every transaction. See https://wiki.mozilla.org/Services/Sync/SyncKey/J-PAKE Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
Nelson B Bolyard wrote: Brian Smith wrote: I personally would like to find a way to avoid calling these internal functions from within Firefox--especially since there's no way to detect incompatibilities at compile-time and because the interface to these functions isn't frozen. To what functions are you referring when you say the interface to these functions isn't frozen. ?? The functions you listed below (which I haven't copied here)? Yes. Speaking only for myself, I have no objection to offering the mp_int bignum API as a public API out of freebl3. If people are open to having the J-PAKE building blocks in FreeBL, then we wouldn't need MPI to be part of the public API. The main concern with putting J-PAKE building blocks in NSS is getting that NSS release out for FF4.0. - the wisdom of making Mozilla products even MORE dependent on shared secrets and passwords than they already are, when, for at least a decade, shared secrets in general and passwords in particular have been regarded by security experts as more part of the problem than part of the solution. Letting mozilla products become a playground for home-baked crypto protocols. That's a gate you'll find difficult to close once it is allowed to be opened. At the present time, the only thing you can do with the Sync account password is delete the data off the server and/or associate a different (strong) sync key with the account. Besides J-PAKE, it looks like Sync crypto will end up using quite simple/standard/boring algorithms techniques. Once things are nailed down a little more, there will be a complete design document (and code, of course) for public review. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On Thu, Oct 21, 2010 at 3:53 PM, Nelson B Bolyard nel...@bolyard.me wrote: I'd say the interfaces to those functions (more precisely, their signatures) are quite frozen. The mp_int bignum package API is so frozen as to have become something of a standard of its own. There are now at least 3 different implementations known to me that are all API compatible, differing only in the content of the (opaque) mp_int structure itself. Speaking only for myself, I have no objection to offering the mp_int bignum API as a public API out of freebl3. They're not presently exported from the freebl shared lib at all, but IMO, they could be. We merely wanted to minimize the exported API. We also need to undo some processor-version-specific type definitions. An example is the mp_digit type for 64-bit Solaris SPARC. mp_digit is defined differently for different versions of the SPARC v9a processors: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/Makefilerev=1.115mark=420-432#420 Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
This is a resend. Don't know why my previous copy went only to Marsh. I intended it to go to the list as well. On 2010-10-21 16:50 PDT, Marsh Ray wrote: On 10/21/2010 05:53 PM, Nelson B Bolyard wrote: - Letting mozilla products become a playground for home-baked crypto protocols. That's a gate you'll find difficult to close once it is allowed to be opened. Since when have Mozilla products not been a playground? It IS a playground, in the sense that people can develop add-ons to do whatever their hearts desire, and Mozilla actively encourages that. I'm referring to the functionality in the base product, and particularly to the security functionality in the base product. Users expect that Mozilla product security, out of the box (so to speak), with no add-ons present, is going to be very good. And once added, features are seldom removed. Look at how long it is still taking to get browsers to be secure with respect to renegotiation out-of-the-box. It's because users have become dependent on that bad old stuff and won't let go, even if it's bad for them. Who put up a gate in the first place anyway? Would you really have app developers go elsewhere for bignums? I'm talking about putting JBAKE (or whatever it is) into the base product. That's the motive behind this request. It's not for add-on developers. It's because someone wants to put Do you really think it would inhibit anyone from baking with crypto? I don't care about what people do with add-ons. They're not even at issue here. I do care about what Mozilla offers to its users in the products that bear its name, under the pretense of security. Security isn't about a pile of cool-sounding features. It's about assurances. There are people within Mozilla who want to add to the feature list, want to have more bragging rights, want to claim to be the first with some new buzzword. That's utterly harmless when the new buzzword is some new UI feature that changes pixels on a screen, but in the security space, more care is needed to maintain the assurances. I want my playground and Easy Bake crypto oven. Or, more precisely, it bugs me that an open project like Mozilla would restrict tools on the too dangerous for mere mortals principle. Marsh, Most users have no idea, draw no distinction, among the various security protocols, mechanisms, schemes used within a product like their browser. They have no idea where the responsibilities of a protocol end and the responsibilities of the program's UI begin. When their security is violated, they just lump it all together. That's why SSL/TLS keep getting smeared for faults that are purely UI faults. We read, monthly if not weekly, pronouncements in the press saying that SSL has failed because users clicked past security warnings, or because the browser was fooled by some clever web page content (e.g. JavaScript) into displaying the wrong information to identify the source of that content, or because badly-designed browser security UI, which is utterly indistinguishable from web page content, is subverted to fool users into taking actions that harm their own security, or simply because users continue to fall for emails bearing dire warnings that appear to come from their banks, that make them SO upset that they fail to notice the web page into which they typed their bank password was NOT their bank's page. None of these problems is in any way a fault of the SSL/TLS protocols, but even readers of this group have tried to argue that they are. So, when it comes to user security, Mozilla needs to take care about who it lets into its bed. One foul piece of security in the base product will besmirch ALL the product's security features. cheap_shot So if Mozilla's got such high standards on authentication and such, they can put up even one add-on that doesn't say (Author not verified) in my browser: https://addons.mozilla.org/en-US/firefox/addon/15003/ https://addons.mozilla.org/en-US/firefox/addon/11950/ /cheap_shot I don't think it's a cheap shot. I'm not wild about that, either. I think it does show, however, a difference in degree of care between things that are offered as products of Mozilla versus addons by whomever. That's appropriate, to some degree, in my opinion. I'm just trying to ensure that the newest comer to Mozilla's security development community is aware of some of these issues. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 2010-10-22 11:35 PDT, Wan-Teh Chang wrote: On Thu, Oct 21, 2010 at 3:53 PM, Nelson B Bolyard nel...@bolyard.me wrote: I'd say the interfaces to those functions (more precisely, their signatures) are quite frozen. The mp_int bignum package API is so frozen as to have become something of a standard of its own. There are now at least 3 different implementations known to me that are all API compatible, differing only in the content of the (opaque) mp_int structure itself. Speaking only for myself, I have no objection to offering the mp_int bignum API as a public API out of freebl3. They're not presently exported from the freebl shared lib at all, but IMO, they could be. We merely wanted to minimize the exported API. We also need to undo some processor-version-specific type definitions. An example is the mp_digit type for 64-bit Solaris SPARC. mp_digit is defined differently for different versions of the SPARC v9a processors: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/Makefilerev=1.115mark=420-432#420 Hmm. The mp_int struct itself should be opaque in a public definition. So there shuold be no need to change the machine-dependent definitions of the contents of that struct (including the array to which it points). But I know that mp_digit is also used for types in the function signatures, and that IS an issue... I think this says that the task is feasible but requires more time to think about all its implications. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 10/20/2010 05:13 PM, Brian Smith wrote: See https://bugzilla.mozilla.org/show_bug.cgi?id=601645. The following internal functions and data structures in FreeBL that would be used Firefox 4.0 Sync's J-PAKE implementation through JSCtypes (a mechanism for calling native code through Javascript). I personally would like to find a way to avoid calling these internal functions from within Firefox--especially since there's no way to detect incompatibilities at compile-time and because the interface to these functions isn't frozen. We might also have the option of rewriting the J-PAKE implementation in C, include it in NSS, and making the J-PAKE functionality part of the public API of NSS. Another option would be to rewrite it in C, add it to NSS, but only enable it in a special (Firefox-specific) configuration of FreeBL. The default option seems to be to keep accessing these internal functions and data structures through JavaScript, and rely on NSS distributors to not change them. I am eager to hear others' suggestions. Note that Sync's design is fundamentally incompatible with FIPS mode and consequently there's no need to consider FIPS mode concerns. We will just disable Sync (or require the user to disable it) in FIPS mode. Cheers, Brian SHA1Context SHA1_Hash SHA1_HashBuf SHA1_NewContext SHA1_DestroyContext SHA1_Begin SHA1_Update SHA1_End The exported equivalence to these functions are: #include sechash.h HASHContext HASH_HashBuf HASH_Create HASH_Destroy HASH_Begin HASH_Update HASH_End (It's not an accident that they are similarly named). HASH_Create takes a HASH_HashType to say what time of hash you are using. In addition there is a function that returnes the expected length based on HASH_HashType, or the HASHContext. There is also a function that maps oids to HASH_HashType. The latter two would help you if you need hash agility (which you should probably think about). If your protocal uses oids to specify your hash function, then you won't even need to know what the real hash is under the covers. mp_sign mp_size mp_err mp_digit mp_int mp_init mp_clear mp_set mp_sub_d mp_sub mp_cmp mp_cmp_d mp_mod mp_addmod mp_submod mp_mulmod mp_exptmod mp_read_raw mp_raw_size mp_toraw mp_read_radix mp_radix_size mp_toradix It depends on what J-PAKE is doing. My guess is it's doing a zero knowledge proof algorithm (given the need for add and sub), which is generally useful. I would be view a patch that puts the zero knowledge proof into freebl with favor (and would clear out time to review such a patch). If we are just talking DH or RSA operations, there are public equivalents to those as well. bob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 2010-10-20 17:13 PDT, Brian Smith wrote: See https://bugzilla.mozilla.org/show_bug.cgi?id=601645. The following internal functions and data structures in FreeBL that would be used Firefox 4.0 Sync's J-PAKE implementation through JSCtypes (a mechanism for calling native code through Javascript). I personally would like to find a way to avoid calling these internal functions from within Firefox--especially since there's no way to detect incompatibilities at compile-time and because the interface to these functions isn't frozen. To what functions are you referring when you say the interface to these functions isn't frozen. ?? The functions you listed below (which I haven't copied here)? I'd say the interfaces to those functions (more precisely, their signatures) are quite frozen. The mp_int bignum package API is so frozen as to have become something of a standard of its own. There are now at least 3 different implementations known to me that are all API compatible, differing only in the content of the (opaque) mp_int structure itself. Speaking only for myself, I have no objection to offering the mp_int bignum API as a public API out of freebl3. They're not presently exported from the freebl shared lib at all, but IMO, they could be. We merely wanted to minimize the exported API. But cryptography isn't the only user of bignums, and IMO, it doesn't make sense to for Mozilla to have yet another bignum library when NSS's is suitable for most purposes. The hash functions you mentioned ARE already exported and there's even a public API for them (albeit slightly different, as Bob has explained). IMO, apart from the mundane technical issue of making hash and bignum functions public, there are some bigger questions, such as: - the wisdom of making Mozilla products even MORE dependent on shared secrets and passwords than they already are, when, for at least a decade, shared secrets in general and passwords in particular have been regarded by security experts as more part of the problem than part of the solution. - Letting mozilla products become a playground for home-baked crypto protocols. That's a gate you'll find difficult to close once it is allowed to be opened. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
On 10/21/2010 05:53 PM, Nelson B Bolyard wrote: IMO, apart from the mundane technical issue of making hash and bignum functions public, there are some bigger questions, such as: - the wisdom of making Mozilla products even MORE dependent on shared secrets and passwords than they already are, when, for at least a decade, shared secrets in general and passwords in particular have been regarded by security experts as more part of the problem than part of the solution. Passwords suck, agreed. But developers will code this stuff in Javascript anyway. By not withholding those solid primitives which already exist someone has a shot at making something that's not leaking through every imaginable side-channel. - Letting mozilla products become a playground for home-baked crypto protocols. That's a gate you'll find difficult to close once it is allowed to be opened. Since when have Mozilla products not been a playground? Who put up a gate in the first place anyway? Would you really have app developers go elsewhere for bignums? Do you really think it would inhibit anyone from baking with crypto? I want my playground and Easy Bake crypto oven. Or, more precisely, it bugs me that an open project like Mozilla would restrict tools on the too dangerous for mere mortals principle. cheap_shot So if Mozilla's got such high standards on authentication and such, they can put up even one add-on that doesn't say (Author not verified) in my browser: https://addons.mozilla.org/en-US/firefox/addon/15003/ https://addons.mozilla.org/en-US/firefox/addon/11950/ /cheap_shot - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync
See https://bugzilla.mozilla.org/show_bug.cgi?id=601645. The following internal functions and data structures in FreeBL that would be used Firefox 4.0 Sync's J-PAKE implementation through JSCtypes (a mechanism for calling native code through Javascript). I personally would like to find a way to avoid calling these internal functions from within Firefox--especially since there's no way to detect incompatibilities at compile-time and because the interface to these functions isn't frozen. We might also have the option of rewriting the J-PAKE implementation in C, include it in NSS, and making the J-PAKE functionality part of the public API of NSS. Another option would be to rewrite it in C, add it to NSS, but only enable it in a special (Firefox-specific) configuration of FreeBL. The default option seems to be to keep accessing these internal functions and data structures through JavaScript, and rely on NSS distributors to not change them. I am eager to hear others' suggestions. Note that Sync's design is fundamentally incompatible with FIPS mode and consequently there's no need to consider FIPS mode concerns. We will just disable Sync (or require the user to disable it) in FIPS mode. Cheers, Brian SHA1Context SHA1_Hash SHA1_HashBuf SHA1_NewContext SHA1_DestroyContext SHA1_Begin SHA1_Update SHA1_End mp_sign mp_size mp_err mp_digit mp_int mp_init mp_clear mp_set mp_sub_d mp_sub mp_cmp mp_cmp_d mp_mod mp_addmod mp_submod mp_mulmod mp_exptmod mp_read_raw mp_raw_size mp_toraw mp_read_radix mp_radix_size mp_toradix -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
