On Tue, Nov 19, 2013 at 9:14 AM, Kurt Roeckx k...@roeckx.be wrote:
On Mon, Nov 18, 2013 at 06:47:08PM -0800, Wan-Teh Chang wrote:
On Mon, Nov 18, 2013 at 4:57 PM, Brian Smith br...@briansmith.org wrote:
Also, AES implementations are highly optimized, well-audited,
well-tested, and are more
On Mon, Nov 18, 2013 at 06:47:08PM -0800, Wan-Teh Chang wrote:
On Mon, Nov 18, 2013 at 4:57 PM, Brian Smith br...@briansmith.org wrote:
Also, AES implementations are highly optimized, well-audited,
well-tested, and are more likely to be side-channel free. Camellia
doesn't get used very
On Sun, Nov 10, 2013 at 4:39 AM, Kurt Roeckx k...@roeckx.be wrote:
On Sat, Nov 09, 2013 at 02:57:48PM -0800, Brian Smith wrote:
Last week, I also learned that ENISA, a European standards group,
recommends Camellia alongside AES as a future-proof symmetric cipher
algorithm; see [4].
They
On 01/11/13 09:41, Dirkjan Ochtman wrote:
His Bugzilla status suggests Brian might have left Mozilla:
Brian Smith (:briansmith, was :bsm...@mozilla.com; NEEDINFO me if you
want a response)
No, Brian hasn't left Mozilla - he just decided to use a different
primary email address.
I too would
Mountie Lee moun...@paygate.net wrote:
SEED was adopted to encourage escaping ActiveX dependency in Korea
e-commerce environment.
Many people at Mozilla, including us platform engineers, want this
too. Our goal is to get rid of plugins on the internet completely.
And, also, personally I think
On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote:
So what needs to happen so that we can move on with this?
I still have the same question. Nothing seems to be happening.
Kurt
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent jul...@linuxwall.info wrote:
It seems that AES-256 is always 25% to 30% slower than AES-128, regardless of
AES-NI, or the CPU family.
The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which is
probably fast enough for any
On Mon, Oct 7, 2013 at 4:50 PM, Brian Smith br...@briansmith.org wrote:
On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent jul...@linuxwall.info
wrote:
It seems that AES-256 is always 25% to 30% slower than AES-128,
regardless of AES-NI, or the CPU family.
The slowest implementation of
Hi.
thanks for mail.
the reason why SEED support give not so much impact is
SEED is not used alone but used with other crypto algorithms (hash,
asymmetric...)
SHA2 hash required in e-commerce transaction by the korean regulation.
and which is also used in TLSv1.1+.
SEED can be used under
On Mon, Oct 7, 2013 at 6:05 PM, Mountie Lee moun...@paygate.net wrote:
SHA2 hash required in e-commerce transaction by the korean regulation.
and which is also used in TLSv1.1+.
Hi,
First, we will be enabling TLS 1.2 in Firefox very soon.
But, I think you may be referring to SHA-2-based
Hi.
let me add my comment for SEED.
SEED was adopted to encourage escaping ActiveX dependency in Korea
e-commerce environment.
the impact of mozilla's effort was not figured out well.
but it has meaning and VERY helpful for us to expand web standard
environment (plugin free)
at last year,
let me add one more.
SEED is normally used for TLS 1.1+ because the SSL Certificate issued from
Korean CA use SHA2 hash algorithm.
browser support for TLS 1.1 is limited currently.
I expect that is one of the reasons why Korean web servers are not add SEED
Cipher suites in SSL configuration.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 13/09/13 04:52, Julien Pierre wrote:
snip
Some servers also ignore the order of cipher suites in the Clienthelo
anyway in some cases, and choose whatever they prefer among the client
cipher suite list regardless of order, even though this doesn't follow
the TLS specs.
Julien, I disagree
On 2013-09-12 23:11, Stefan Arentz wrote:
How about mobile?
Mobile is not an issue.
Updated table that contains speed test on Android with an ARMv7 (Galaxy S3):
http://jve.linuxwall.info/ressources/taf/aesmeasurements.txt
You can see that the ARM7 does AES-{128,256} in the 50 to 70MB/s
On 2013-08-26 17:24, Brian Smith wrote:
Conversely, it isn't clear that AES-256 offers any significant security
advantage over AES-128, though it is clearly slower, even on my
AES-NI-equipped Core i7 processor. First, AES-128 has held up pretty well
so that it might just be good enough in
Julien,
On 9/12/2013 07:06, Julien Vehent wrote:
If performance was the only reason to prefer AES-128, I would disagree
with the proposal. But your other arguments regarding AES-256 not
provided additional security, are convincing.
The performance is still an issue for servers. More servers
On 2013-09-12 22:01, Julien Pierre wrote:
Julien,
On 9/12/2013 07:06, Julien Vehent wrote:
If performance was the only reason to prefer AES-128, I would disagree
with the proposal. But your other arguments regarding AES-256 not provided
additional security, are convincing.
The performance
How about mobile?
What about the initial key exchange that SSL/TLS does? I thought that was the
biggest CPU killer?
S.
- Original Message -
From: Julien Vehent jul...@linuxwall.info
To: Julien Pierre julien.pie...@oracle.com
Cc: mozilla's crypto code discussion list
Julien,
On 9/12/2013 19:35, Julien Vehent wrote:
aes-256-cbc with AES-NI does 543763.11kB/s. That's 4.35Gbps of AES
bandwidth on a single core.
On a decent 8 core load balancer, dedicate 4 to TLS, and you get
17.40Gbps of AES bandwidth.
I don't this AES is close to being the limiting factor
On Mon, Sep 09, 2013 at 07:20:57PM +0100, Rob Stradling wrote:
Probably worth keeping an eye on this new draft and the related
discussion on the TLS list...
http://tools.ietf.org/html/draft-sheffer-tls-bcp-00
Note that the recommended cipher there isn't in Brian's proposal,
and I've already
On Friday, August 9, 2013 5:30:26 AM UTC+3, Brian Smith wrote:
Please see https://briansmith.org/browser-ciphersuites-01.html
Thank you for this.
I'm a bit skeptical about whether eliminating handshake fingerprinting is worth
the disincentive to improve the set of ciphersuites. And I'm
On 22/08/13 11:50, Alan Braggins wrote:
On 21/08/13 18:23, Zack Weinberg wrote:
I share concern
about new side channel attacks due to GMAC, though.
You aren't alone.
https://bugzilla.mozilla.org/show_bug.cgi?id=868948
I asked a friend who works for ARM about the chances of
constant time
On 09/08/13 03:30, Brian Smith wrote:
Please see https://briansmith.org/browser-ciphersuites-01.html
This proposal promotes ECC.
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
Schneier: Prefer conventional discrete-log-based systems over
elliptic-curve
On Mon, Sep 9, 2013 at 5:16 PM, Gervase Markham g...@mozilla.org wrote:
This proposal promotes ECC.
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
Schneier: Prefer conventional discrete-log-based systems over
elliptic-curve systems; the latter have
On Sep 9, 2013, at 11:16 AM, Gervase Markham g...@mozilla.org wrote:
On 09/08/13 03:30, Brian Smith wrote:
Please see https://briansmith.org/browser-ciphersuites-01.html
This proposal promotes ECC.
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
On Mon, Sep 09, 2013 at 11:29:19AM -0400, Stefan Arentz wrote:
On Sep 9, 2013, at 11:16 AM, Gervase Markham g...@mozilla.org wrote:
On 09/08/13 03:30, Brian Smith wrote:
Please see https://briansmith.org/browser-ciphersuites-01.html
This proposal promotes ECC.
The NSA recommends ECC for encrypting secret and top secret information.
So if the NSA have backdoored the NIST curves somehow, presumably
they're 100% confident that the details of the backdoor won't get leaked
or discovered by external researchers!
On 09/09/13 17:15, Kurt Roeckx wrote:
On
Probably worth keeping an eye on this new draft and the related
discussion on the TLS list...
http://tools.ietf.org/html/draft-sheffer-tls-bcp-00
On 09/09/13 17:15, Kurt Roeckx wrote:
On Mon, Sep 09, 2013 at 11:29:19AM -0400, Stefan Arentz wrote:
On Sep 9, 2013, at 11:16 AM, Gervase Markham
So what needs to happen so that we can move on with this?
Kurt
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea rrel...@redhat.com wrote:
So looking at this list, I think we have a major inconsistency.
We put Ephemeral over non-ephemeral, but we put 128 over 256.
While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think
in doing so we are
On Mon, Aug 26, 2013 at 2:24 PM, Brian Smith br...@briansmith.org wrote:
Something to note is that MSIE has always put AES-128 cipher suites ahead
of AES-128 cipher suites. They also put RSA cipher suites ahead of PFS
cipher suites, though.
I meant: MSIE has always put AES-128 cipher suites
On 08/26/2013 02:24 PM, Brian Smith wrote:
On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea rrel...@redhat.com wrote:
So looking at this list, I think we have a major inconsistency.
We put Ephemeral over non-ephemeral, but we put 128 over 256.
While I'm OK with Ephemeral (PFS) over
On Mon, Aug 26, 2013 at 05:16:43PM -0700, Robert Relyea wrote:
2) It does have a significant downside speed wise. I was responsible
for measuring this once from the server perspective (we were trying to
convince people to use ECC. I could only get wins over RSA at the 2048
bit range with ECDH
On 22/08/13 19:21, Robert Relyea wrote:
The attack profile protection of PFS versus non-PFS is basically two points:
1) some government agency could force a server to give up it's private
keys and decrypt all the traffic sent to that server. But we already
know that government agencies with
On 08/23/2013 02:03 AM, Gervase Markham wrote:
On 22/08/13 19:21, Robert Relyea wrote:
The attack profile protection of PFS versus non-PFS is basically two points:
1) some government agency could force a server to give up it's private
keys and decrypt all the traffic sent to that server. But
On 21/08/13 18:23, Zack Weinberg wrote:
On 2013-08-19 2:06 PM, Kurt Roeckx wrote:
I understand that GCM is faster, but the implementations might have side
channel attacks. So I'm not sure if GCM or CBC is better, but
we should probably prefer GCM or CBC.
GCM is (AIUI) preferred because it's
On 08/19/2013 11:06 AM, Kurt Roeckx wrote:
On 08/09/2013 04:30 AM, Brian Smith wrote:
Please see https://briansmith.org/browser-ciphersuites-01.html
First, this is a proposal to change the set of sequence of ciphersuites
that Firefox offers.
So I think there are a whole bunch of things
On 08/16/2013 03:05 PM, Wan-Teh Chang wrote:
On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco cvie...@mozilla.com wrote:
Hello Brian
I think this proposal has 3 sections.
1. Unifing SSL behavior on browsers.
2. Altering the criteria for cipher suite selection in Firefox (actually
NSS)
3.
On 19/08/13 19:06, Kurt Roeckx wrote:
I understand that GCM is faster, but the implementations might have side
channel attacks. So I'm not sure if GCM or CBC is better, but
we should probably prefer GCM or CBC.
GCM (while recognizing that it isn't widely supported yet).
(At least unless
On 2013-08-19 2:06 PM, Kurt Roeckx wrote:
I understand that GCM is faster, but the implementations might have side
channel attacks. So I'm not sure if GCM or CBC is better, but
we should probably prefer GCM or CBC.
GCM is (AIUI) preferred because it's immune to BEAST. I share concern
about
On 2013-08-20 2:33 PM, Tom Ritter wrote:
On 20 August 2013 14:26, Gervase Markham g...@mozilla.org wrote:
On 19/08/13 04:07, Brian Smith wrote:
When risk is there to a user of having a network eavesdropper able to
tell that they are using a particular browser? If I had an exploit for a
On 08/09/2013 04:30 AM, Brian Smith wrote:
Please see https://briansmith.org/browser-ciphersuites-01.html
First, this is a proposal to change the set of sequence of ciphersuites
that Firefox offers.
So I think there are a whole bunch of things where we have 2 options,
and it's not always
On Mon, Aug 19, 2013 at 08:06:49PM +0200, Kurt Roeckx wrote:
I understand that the MAC itself doesn't make much difference, but
we should probably avoid MD5. I see no SHA256 MACs except for GCM
which probably isn't a problem.
I'm having mixed feelings about SHA1 / SHA256. I think it makes
On 19/08/13 04:07, Brian Smith wrote:
When risk is there to a user of having a network eavesdropper able to
tell that they are using a particular browser? If I had an exploit for a
particular browser, I'd just try it anyway and see if it worked. That
seems to be the normal pattern.
One
On 20 August 2013 14:26, Gervase Markham g...@mozilla.org wrote:
On 19/08/13 04:07, Brian Smith wrote:
When risk is there to a user of having a network eavesdropper able to
tell that they are using a particular browser? If I had an exploit for a
particular browser, I'd just try it anyway and
On Thu, Aug 15, 2013 at 10:15 AM, Chris Richardson ch...@randomnonce.orgwrote:
I believe this plan would have poor side effects. For example, if Apple
ships clients with a broken ECDSA implementation [0], a server cannot
detect detect if a connecting client is an Apple product and avoid the
On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco cvie...@mozilla.com wrote:
Hello Brian
I think this proposal has 3 sections.
1. Unifing SSL behavior on browsers.
2. Altering the criteria for cipher suite selection in Firefox (actually
NSS)
3. removing certain cipher suites from the default
On Fri, Aug 16, 2013 at 5:58 PM, Wan-Teh Chang w...@google.com wrote:
On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling rob.stradl...@comodo.com
wrote:
Wan-Teh, why do you think Firefox should specify a preference for ECDSA
over
RSA?
Because ECDSA is more secure than RSA, and ECC
On Mon, Aug 12, 2013 at 6:52 AM, Gervase Markham g...@mozilla.org wrote:
On 09/08/13 18:12, Brian Smith wrote:
No, each combination is hard-coded into its own distinct code point that
is
registered with IANA:
On 15/08/13 18:15, Chris Richardson wrote:
I believe this plan would have poor side effects. For example, if Apple
ships clients with a broken ECDSA implementation [0], a server cannot
detect detect if a connecting client is an Apple product and avoid the use
of ECDSA in that subset of
On Fri, August 16, 2013 6:36 am, Rob Stradling wrote:
On 15/08/13 18:15, Chris Richardson wrote:
I believe this plan would have poor side effects. For example, if Apple
ships clients with a broken ECDSA implementation [0], a server cannot
detect detect if a connecting client is an Apple
Hello Brian
I think this proposal has 3 sections.
1. Unifing SSL behavior on browsers.
2. Altering the criteria for cipher suite selection in Firefox (actually
NSS)
3. removing certain cipher suites from the default firefox ciphersuite.
On 1:
I dont see the point, but I am not against.
On 2:
On 8/16/13 11:13 AM, Camilo Viecco wrote:
Hello Brian
I think this proposal has 3 sections.
1. Unifing SSL behavior on browsers.
2. Altering the criteria for cipher suite selection in Firefox
(actually NSS)
3. removing certain cipher suites from the default firefox ciphersuite.
On 1:
I dont
On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco cvie...@mozilla.com wrote:
Hello Brian
I think this proposal has 3 sections.
1. Unifing SSL behavior on browsers.
2. Altering the criteria for cipher suite selection in Firefox (actually
NSS)
3. removing certain cipher suites from the default
On 16/08/13 23:05, Wan-Teh Chang wrote:
snip
8. Authentication: RSA before ECDSA
a. RSA before ECDSA : performance
b. DSA last: not in use
snip
... I would prefer ECDSA over RSA for authentication.
Wan-Teh, why do you think Firefox should specify a preference for ECDSA
over RSA?
On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling rob.stradl...@comodo.com wrote:
Wan-Teh, why do you think Firefox should specify a preference for ECDSA over
RSA?
Because ECDSA is more secure than RSA, and ECC implementations will
become faster over time.
The ordering of RSA and ECDSA is really
I believe this plan would have poor side effects. For example, if Apple
ships clients with a broken ECDSA implementation [0], a server cannot
detect detect if a connecting client is an Apple product and avoid the use
of ECDSA in that subset of connections. Instead, ECDSA suddenly becomes
unsafe
On 08/09/2013 10:12 AM, Brian Smith wrote:
On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham g...@mozilla.org wrote:
* Can you provide some background or references on exactly how
ciphersuite construction and choice works? Can I invent e.g.
TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random
On 09/08/13 18:12, Brian Smith wrote:
No, each combination is hard-coded into its own distinct code point that is
registered with IANA:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4.
This is a design choice based on the fact that many crypto modules
Hi Brian,
On 09/08/13 03:30, Brian Smith wrote:
Please see https://briansmith.org/browser-ciphersuites-01.html
Suggestions for improvements are encouraged.
Thanks for this. Here are my questions:
* Can you provide some background or references on exactly how
ciphersuite construction
On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham g...@mozilla.org wrote:
* Can you provide some background or references on exactly how
ciphersuite construction and choice works? Can I invent e.g.
TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of
elements? Can any combination
Thoughts, as a random passerby:
Of course I quite like the prioritization of (EC)DHE.
I think standardizing on a ciphersuite preference order with the aims
of reducing fingerprinting is a worthwhile (although wildly difficult)
goal for SSL _libraries_, but less so for browsers - to the point of
Please see https://briansmith.org/browser-ciphersuites-01.html
First, this is a proposal to change the set of sequence of ciphersuites
that Firefox offers. Secondly, this is an invitation for other browser
makers to adopt the same sequence of ciphersuites to maximize
interoperability, to minimize
64 matches
Mail list logo