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. 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/ - Marsh -- 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: Firefox Sync, Key Exchange/Entry, and FIPS (was Re: NSS linkage and FIPS-140 compliance for Firefox)
On 10/20/2010 06:29 PM, Brian Smith wrote: >> Brian Smith wrote: >> >>> (Because of Firefox Sync, we are now always going to have crypto >>> features that won't work in FIPS mode.) >>> >> Sigh, ignoring FIPS mode in a feature, is usually a red flag. It means >> you are handling CSP's where you really shouldn't be. Firefox Sync >> *CAN* be implemented in FIPS mode, and we should work to make sure >> that happens. >> > Because of the way key exchange and key entry are done in Firefox Sync, even > if it worked in FIPS mode, it wouldn't be FIPS compliant. Because of > usability constraints, Sync will use an unapproved key exchange mechanism > (J-PAKE). And, it also allows manual key entry. For compatibility with > previous versions we also have to support encryption/authentication keys > derived from weaker keys via PBKDF2, though the new Sync crypto design will > avoid PBKDF2 for new users. > OK, use of standard, but non-FIPS algorithms are fine. It's really the key management portions that are a bigger issue. (Of course to users that require FIPS it's not, but that's not the context we are talking about here;). bob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Thunderbird: "Could not verify this certificate for unknown reasons"
On 20. 10. 2010 21:01, Nelson B Bolyard wrote:
On 2010-10-20 09:54 PDT, Matej Kurpel wrote:
Hello,
I have set up my own CA and issued one certificate signed by this CA.
However, I cannot use this certificate to send signed e-mail from
Thunderbird. It says "Could not verify this certificate for unknown
reasons".
PSM's infamous "for an unknown reason" error message,
the bane of my existence for about a decade now. See
https://bugzilla.mozilla.org/show_bug.cgi?id=desired
When any NSS function fails, NSS always provides a reason code. But years
ago, the manager of the group responsible for implementing the GUI for
Mozilla's crypto security decided that error details were unimportant, and
so, to save schedule time, he allowed his employee to do
a very incomplete job of producing error message strings for the various
error codes, and simply present a default string in all other cases that
says "for an unknown reason". We've been plagued with that ever since.
In all the years since then, it has never been important to Mozilla UI
folks to fix this. It seems to be an entrance requirement to get into GUI
design school. They ask you "is security UI design important?", and if
you say "yes", or even hesitate to say "NO!", you're out. ("HELL NO!" is
the preferred answer.)
So, here's what you do. Use one of NSS's command line tools to verify
your certificate chain for the email certificate usage, and see what it
says.
Thank you, Nelson. I have downloaded the NSS utils and used the
certutil. I have copied *.db files from Thunderbird's profile folder to
the same folder in which certutil and other utils reside. And I have put
both my CA certificate (ca_cert.der with subject address
mekova...@spam.la) and the user certificate (cert.der with subject
address mkur...@gmail.com), in the same folder.
Then I made this to validate my user certificate:
certutil -V -n mkur...@gmail.com -u -SR -e -l -d .
It said:
certutil: could not find certificate named "mkur...@gmail.com": security
library
: bad database.
So, apparently the user certificate wasn't in the database. I then tried
to verify the CA certificate:
certutil -V -n mekova...@spam.la -u -SR -e -l -d .
certutil: certificate is valid
Then I added the user certificate into the database and tried to verify
it again:
certutil -A -n mkur...@gmail.com -t Pug -d . -i cert.der
certutil -V -n mkur...@gmail.com -u -SR -e -l -d .
certutil: certificate is valid
This looks like Thunderbird cannot find the user certificate in its
database. Well, it shouldn't anyway, since it resides on the token
provided by a PKCS#11 module I am developing. However, in its properties
it says it couldn't verify the certificate for unknown reasons. And the
CA certificate is added into the authorities correctly. Any more ideas,
please?
M. Kurpel
--
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
JSS4.DLL and JSS.jar for Windows 64 bits
Hi there, I´m trying to compile the JSS in the Windows 64 bits platform and I have found many problems to do that. I have seen many posts in the internet with many problems too. I just want use the JSS and not compile it. Could the Mozilla team publishs the JSS binaries (dll and jar) compiled in the Windows 64 bits for us like the existing in older JSS packag ? Thank you very much Ramirez, Marcio -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Discussion Forums reconfiguration glitch: news posts will not propagate
Unfortunately, Giganews had a problem switching the four groups to "moderated" status. They are working on it, but in the mean time, posts made via the news interface will not propagate to the mail and Google Groups interfaces, for lack of "approval" stamps. Therefore, if you read this group via news, be aware than any posts you make in the next little while will not be seen by people using mail or Google Groups. We will provide an update when this situation is resolved. This is why we test these things on a small number of groups first :-) Thank you for your patience. Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Discussion forums anti-spam: configuration change
On 20/10/10 19:36, Nelson B Bolyard wrote: I think I'm responsible for (moderate) this group, and I only just learned about this from this posting of yours. Nonetheless, I'm quite happy for this group to be among your guinea pigs. Thanks. Hi Nelson, I'm sorry, I thought you were looped in to the plan to make these changes. Still, I'm glad you are happy about it :-) Although there has been a technical hitch[0], so the next 24 hours might be a bit rocky. This is why we picked guinea pigs! :-) Gerv [0] https://bugzilla.mozilla.org/show_bug.cgi?id=598060#27 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
