Hi all !
I managed to make what I wanted to work. I would like to thank you for
all you've done. You've been terrific.
Thanks,
Gregory.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Nelson B Bolyard wrote:
Sounds like you're not running your build. Are you perhaps still getting
the 'system" libraries in your tests, rather than your own built libs?
I made some progress today.
Damn Nelson, you were right. I got to say I don't know where else it
could have been from but
Wan-Teh Chang wrote:
Without looking at your code, I'm afraid that we won't be able to help much.
Yes, I know it's difficult to guess what I may have done. That's why I
provide in attachment a patch supposed to provide a "new" cipher named
MYC as MYCipher. It is actually SEED.
You probab
Jean-Marc Desperrier a écrit :
Wan-Teh Chang wrote:
You can use the NSS command-line tool 'ssltap' to inspect the SSL
handshake
messages:http://www.mozilla.org/projects/security/pki/nss/tools/ssltap.html
It's significantly easier to do it with Wireshark.
Is it easier than the selfserv and
Sorry, my two emails are one after the other.
As I said in the previous one, I copied the SEED. Basically, I did grep
-i seed $(find mozilla -type f -print) -l followed by a grep -irn 0096 *
I copied all the occurences of SEED the cipher and not the ones about
*a* seed and created a new cipher
Robert,
I did what you suggested.
You were right, there is a deeper problem because selfserv doesn't
recognize my cipher if I use the option "-c :0200". I'm told an unknown
cipher has been requested.
But if I use 0084 (which is camellia) it works fine. I used grep to find
every occurrences of
Robert Relyea a écrit :
In sslsock.c, I print ssl3_CipherPrefSetDefault and I can see that my
cipher is not enabled.
Do you have any hints/tests which could help me ? Some tests I could do ?
What am I missing ?
OK, this is your overall problem. If NSS does not have a cipher enabled,
it
Robert Relyea wrote:
this is your overall problem. If NSS does not have a cipher enabled,
it will neither advertise it nor select it, no matter where it is on the
list.
There are two possible reasons for this:
1) New Ciphers are not enabled by default, you need to explicitly turn
on that cip
Hello all !
I added a cipher in NSS and OpenSSL. I would like to create a TLS
session between those two.
In OpenSSL, the tests suite works fine (make tests) and I can get a
working TLS tunnel with my cipher.
I guess my problem is in NSS, that's why I ask for your help. At this
time, the ciph
Wan-Teh Chang wrote:
On 05/03/10 13:04, Gregory BELLIER wrote:
Hi !
Is there a place somewhere in the code of thunderbird 2 where there is a
cipher order for TLS negociation ?
Thanks in advance for your time.
Hi,
The order of TLS/SSL cipher suites in NSS is hardcoded.
It is
Ludovic Hirlimann a écrit :
On 05/03/10 13:04, Gregory BELLIER wrote:
Hi !
Is there a place somewhere in the code of thunderbird 2 where there is a
cipher order for TLS negociation ?
Thanks in advance for your time.
We use NSS for that - so the answer is probably in the code of NNS
Konstantin Andreev a écrit :
On Wen, 03 Jun 2009, Nelson B Bolyard wrote:
Finally, I will add that (IINM) Thunderbird 3 has support for AES.
I don't know about the SHA1 vs SHA2 issue.
No, it hasn't, TB hardcodes SHA1. No variations:
( begin cite )
nsresult
nsMsgComposeSecure::M
Hello Konstantin,
Konstantin Andreev a écrit :
It could be a great enhancement if Thunderbird could allow to
user-override the automated cipher selection.
That's exactly what I wanted to do. In this case, it's just how I
thought it has to be done : hack the code to override the cipher selecti
Nelson B Bolyard a écrit :
On 2009-12-10 02:12 PST, Gregory BELLIER wrote:
Hi everyone !
I noticed the 3DES cipher is used to encrypt emails with S/MIME and I
would like to use another one.
According to the version of S/MIME standards that are implemented in
Mozilla mail clients
Hi everyone !
I noticed the 3DES cipher is used to encrypt emails with S/MIME and I
would like to use another one.
This is a comment I've seen in secmime.c :
/*
* XXX Should have a #define somewhere which specifies default
* strong cipher. (Or better, a way to configure, which would
Wan-Teh Chang a e'crit:
On Thu, Dec 3, 2009 at 8:54 AM, Gregory BELLIER
wrote:
But, I still don't understand why we need to do a memcpy after the last
round to save the last ciphered block as the new IV into the context. In my
opinion, it's useless, this context won&#x
Robert Relyea a écrit :
But, I still don't understand why we need to do a memcpy after the
last round to save the last ciphered block as the new IV into the
context. In my opinion, it's useless, this context won't be used anymore.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss
Robert Relyea a écrit :
This code is a direct result of the definition of CBC. The IV is a
random value used to initiate the CBC. Different IVs will generate
completely different output stream
Indeed.
The same IV is needed for encryption and decryption.
If I refer to the sample2 example :
http
Hi ! First of all, thank you for your time.
Wan-Teh Chang a écrit :
2009/12/2 Gregory BELLIER :
Examples :
- For Camellia at the end of camellia_encryptCBC(CamelliaContext *cx, ...) :
lastblock = output;
memcpy(cx->iv, lastblock, CAMELLIA_BLOCK_SIZE);
return SECSuccess;
Hello ML,
First of all, I'm not a crypto expert, that's why I ask this question
which may appear obvious for some of you.
I work on NSS and I've studied the CBC operation mode implementation for
Camellia and SEED ciphers.
I do understand how the CBC works but I don't understand why there is a
20 matches
Mail list logo
