Re: Rus GOST 89
Frank Hecker hec...@mozillafoundation.org writes: Nelson B Bolyard wrote: Today, I see the FSF web site talks about copyright assignment. I don't know all the implications of that, but I presume that it is essentially a relinquishment, except that you keep your own name on the copyrighted work. One last comment on this: Typical copyright assignment agreements transfer all rights in the code to someone else. Note, though, that the FSF's assignment contract licenses the rights back to the contributor. You only give up ownership of the code; you can still use/modify/distribute/etc the contributed code after contributing it to the FSF. But only because they explicitly license it back. (How that interacts with the extent to which the contributed code is a derivative of GPL or LGPL code sounds like an interesting question.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Complete chaos in the FreeBL *hash*_End() semantics.
Hello.
At the moment NSS head supports 6 hash algorithm: md2,md5,sha{,-256,-384,-512}.
However, their implementations in freebl backend have no consistent semantics
for method
*hash*_End( Context *, unsigned char *digest, unsigned int *digestLen,
unsigned int maxDigestLen )
Look how various hashes handle (maxDigestLen REAL_HASH_LENGTH) case:
MD2_End,MD5_End:
PORT_SetError(SEC_ERROR_INVALID_ARGS) then return.
- there is no other indication to the caller about error occured
- they do not care about clearing error if maxDigestLen is sufficient
SHA1_End:
application dies with post-mortem message.
SHA{256,384,512}_End:
return only maxDigestLen of digest
- there is no error indication to the caller at all
I should correctly add GOST hash algorithm to the NSS, but which semantics
should I implement for GOST_End() ?
I would propose to unify *hash*_End() semantics for (maxDigestLen
REAL_HASH_LENGTH) as follows:
1) return only maxDigestLen of digest
2) always set digestLen to the real hash length.
3) do *not* kill application (this is unfriendly), do not SetError(). The caller
can always detect digest buffer shortage from the fact (digestLen
maxDigestLen), and caller now knows required buffer length from digestLen.
Best regards,
--
Konstantin Andreev, software engineer.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Complete chaos in the FreeBL *hash*_End() semantics.
On Tue, Sep 15, 2009 at 8:51 AM, Andreev Konstantin andr...@swemel.ru wrote:
Hello.
At the moment NSS head supports 6 hash algorithm:
md2,md5,sha{,-256,-384,-512}.
However, their implementations in freebl backend have no consistent
semantics for method
*hash*_End( Context *, unsigned char *digest, unsigned int *digestLen,
unsigned int maxDigestLen )
Look how various hashes handle (maxDigestLen REAL_HASH_LENGTH) case:
MD2_End,MD5_End:
PORT_SetError(SEC_ERROR_INVALID_ARGS) then return.
- there is no other indication to the caller about error occured
- they do not care about clearing error if maxDigestLen is sufficient
SHA1_End:
application dies with post-mortem message.
SHA{256,384,512}_End:
return only maxDigestLen of digest
- there is no error indication to the caller at all
I should correctly add GOST hash algorithm to the NSS, but which semantics
should I implement for GOST_End() ?
I would propose to unify *hash*_End() semantics for (maxDigestLen
REAL_HASH_LENGTH) as follows:
1) return only maxDigestLen of digest
2) always set digestLen to the real hash length.
3) do *not* kill application (this is unfriendly), do not SetError(). The
caller can always detect digest buffer shortage from the fact (digestLen
maxDigestLen), and caller now knows required buffer length from digestLen.
Thank you for the bug report. The semantics of SHA{256,384,512}_End
are the closest to what I would expect, based on my experience with
other NSS crypto functions. I would expect that on return, *digestLen
contains the number of bytes written.
Also note that there are Hash_HashBuf functions that require
you to know the output length of a hash algorithm. So I think the
FreeBL hash functions assume that the callers know the hash
output length.
Wan-Teh
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Rus GOST 89
On 2009-09-15 07:47 PDT, Andreev Konstantin wrote: Hello. I am currently in the process of adding support for GOST algorithms (RFC 4357,4490,4491) into the NSS. At this moment I implemented GOST hashing and GOST signature verification algorithms in the NSS. This works throughout the whole stack of mozilla code, from adding GOST X.509 certificate into the PSM GUI to the freebl backend. I'd like to contribute my work to Mozilla, and would like to communicate with one of the NSS project owners/developers for code review and guidelines. Best regards, -- Konstantin Andreev, software engineer. Greetings, Konstantin Andreev, You've come to the right place. Perhaps you have already seen the thread with one nsk yatree about this subject. The NSS team will require a contribution whose level of completeness is approximately the same as that of the Camellia patch. Such a patch would include all the following. implementation of the GOST code added to libfreebl. test program for libfreebl enhanced to test GOST. test script for freebl enhanced to test GOST. implementation of the new PKCS#11 mechanism(s) added to libsoftokn, implementation of the new cipher suites added to libSSL. SSL test programs enhanced to test the new cipher suites. SSL test scripts enhanced to test the new cipher suites. All the new code must be licensed with Mozilla's public tri license. I suggest that you start by filing a bug in bugzilla.mozilla.org, product: NSS, component: libraries, severity: enhancement. You can attach your patch(es) there. We can discuss them there. Please make all patches as unified CVS diffs against the trunk of NSS's CVS tree. e.g. the output of cvs -q diff -Npu Thanks. And welcome to the NSS project. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Complete chaos in the FreeBL *hash*_End() semantics.
On 09/15/2009 08:51 AM, Andreev Konstantin wrote:
Hello.
At the moment NSS head supports 6 hash algorithm:
md2,md5,sha{,-256,-384,-512}.
However, their implementations in freebl backend have no consistent
semantics for method
*hash*_End( Context *, unsigned char *digest, unsigned int
*digestLen, unsigned int maxDigestLen )
Look how various hashes handle (maxDigestLen REAL_HASH_LENGTH) case:
MD2_End,MD5_End:
PORT_SetError(SEC_ERROR_INVALID_ARGS) then return.
- there is no other indication to the caller about error occured
- they do not care about clearing error if maxDigestLen is
sufficient
SHA1_End:
application dies with post-mortem message.
SHA{256,384,512}_End:
return only maxDigestLen of digest
- there is no error indication to the caller at all
I should correctly add GOST hash algorithm to the NSS, but which
semantics should I implement for GOST_End() ?
These are private interfaces for NSS softoken, applications can not call
them directly. It's fine to require maxDigestLen to be at least
REAL_HASH_LENGTH. You may assert or not in GOST.
I would propose to unify *hash*_End() semantics for (maxDigestLen
REAL_HASH_LENGTH) as follows:
1) return only maxDigestLen of digest
2) always set digestLen to the real hash length.
3) do *not* kill application (this is unfriendly), do not
SetError(). The caller can always detect digest buffer shortage from
the fact (digestLen maxDigestLen), and caller now knows required
buffer length from digestLen.
You are assuming applications have access to these functions. If the
caller passes something less than REAL_HASH_LENGTH for maxDigestLen,
then it's a bug in the internals of NSS. If this were to change we would
also update the remaining hash functions.
bob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Rus GOST 89
On 09/15/2009 07:47 AM, Andreev Konstantin wrote: Hello. I am currently in the process of adding support for GOST algorithms (RFC 4357,4490,4491) into the NSS. At this moment I implemented GOST hashing and GOST signature verification algorithms in the NSS. This works throughout the whole stack of mozilla code, from adding GOST X.509 certificate into the PSM GUI to the freebl backend. I'd like to contribute my work to Mozilla, and would like to communicate with one of the NSS project owners/developers for code review and guidelines. Best regards, -- I would like make some points about in this thread: Currently both Seed and Camillia were added directly to NSS softoken. This has the advantage that you can mimic what the other natively supported algorithms do in NSS, it has the disadvantage that it puts your non-FIPS algorithm into our FIPS token, subject to the restrictions of FIPS update. An alternative solution would be to add the new algorithm as a separately loaded PKCS #11 module. NSS is capable to identifying these modules and using them when necessary. At some point I would like to move both Camillia and SEED to this type of module. In fact there is no reason that this module couldn't hold all the non-FIPS algorithms. The one thing I still really need to make this work is a way to automatically add the new algorithm's configuration. (And add the appropriate information to SSL, which currently still needs to have all new cipher suites added programmatically). bob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS version 1.1 + 1.2
On 09/15/2009 10:07 PM, Nelson B Bolyard: On 2009-09-15 11:55 PDT, Eddy Nigg wrote: Does mod_nss (NSS based Apache SSL module aka mod_ssl) support TLS v.1.1 and 1.2? NSS does not support TLS 1.1 or TLS 1.2. Sun's NSS team was planning to add that support in NSS 3.13, but the pending acquisition of Sun has put all of Sun's future NSS development plans on hold indefinitely. OK, thanks for your kind answer! -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
