if this
result still applies for AESNI?
---
Julien Vehent
http://jve.linuxwall.info
--- Speed measurements of AES on several families of CPUs ---
| type| 16_bytes | 64_bytes | 256_bytes | 1024_bytes |
8192_bytes | CPU
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
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
an openssl string to me.
I build a correspondence table between IANA, OpenSSL, GnuTLS and NSS a
couple weeks ago, it might help you convert this tls_ciphers into something
NSS understands.
https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table
---
Julien Vehent
On 2013-12-14 19:47, Kosuke Kaizuka wrote:
Camellia is widely reviewed and chosen as a recommended cipher by
several independent committees.
If CAMELLIA_CBC is dropped by security reason, AES_CBC should be also
dropped.
There is another reason to drop CAMELLIA: AES with AES-NI is 8 times
On 2013-12-15 11:13, Kurt Roeckx wrote:
On Sun, Dec 15, 2013 at 10:46:04AM -0500, Julien Vehent wrote:
On 2013-12-14 19:47, Kosuke Kaizuka wrote:
Camellia is widely reviewed and chosen as a recommended cipher by
several independent committees.
If CAMELLIA_CBC is dropped by security reason
On 2013-12-29 18:30, Kurt Roeckx wrote:
On Sun, Dec 15, 2013 at 11:22:32AM -0500, Julien Vehent wrote:
For the same reason, the server ciphersuite that we recommend at
https://wiki.mozilla.org/Security/Server_Side_TLS
does not drop Camellia, but lists it at the bottom of the ciphersuite.
It's
Hi Aaron,
On 2014-01-02 16:10, Aaron Zauner wrote:
Hi Kurt,
On 02 Jan 2014, at 21:51, Kurt Roeckx k...@roeckx.be wrote:
On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote:
I *think* they want to prefer CAMELLIA to AES, judging by the
published ciphersuite.
But the construction
on people and systems.
It must
protect an activity, but never ever block it entirely.
That being said, I put my comments below.
On 2014-01-02 15:33, Aaron Zauner wrote:
On 02 Jan 2014, at 18:09, Julien Vehent jul...@linuxwall.info
wrote:
Why prefer DHE to ECDHE, when the former is 3 times slower
On 2014-01-02 17:12, Ryan Sleevi wrote:
On Thu, January 2, 2014 1:25 pm, Julien Vehent wrote:
Hi Aaron,
On 2014-01-02 16:10, Aaron Zauner wrote:
Hi Kurt,
On 02 Jan 2014, at 21:51, Kurt Roeckx k...@roeckx.be wrote:
On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote:
I *think
On 2014-01-02 17:12, Ryan Sleevi wrote:
On Thu, January 2, 2014 1:25 pm, Julien Vehent wrote:
Hi Aaron,
On 2014-01-02 16:10, Aaron Zauner wrote:
Hi Kurt,
On 02 Jan 2014, at 21:51, Kurt Roeckx k...@roeckx.be wrote:
On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote:
I *think
On 2014-01-02 18:59, ianG wrote:
On 3/01/14 01:06 AM, Julien Vehent wrote:
3DES isn't broken.
No, but it is end of life. 112bit security for the 2key variant, and an 8
byte block makes it just old. If you've got AES there, use it. Who hasn't
got it?
See https://wiki.mozilla.org
On 2014-01-03 12:58, ianG wrote:
On 3/01/14 19:24 PM, Julien Vehent wrote:
On 2014-01-02 18:59, ianG wrote:
On 3/01/14 01:06 AM, Julien Vehent wrote:
3DES isn't broken.
No, but it is end of life. 112bit security for the 2key variant, and
an 8 byte block makes it just old. If you've got
On 2014-01-03 16:09, Falcon Darkstar Momot wrote:
If I may weigh in, one could certainly argue that there isn't any benefit
in allowing these people to believe that their HTTPS connections are
actually secure when they're using ciphers that we know to be broken (how
much we know them to be
On 2014-01-09 06:41, Kurt Roeckx wrote:
I'm considering if we should also drop support for RC4 on the client side.
At least IE11 on windows 8.1 doesn't do RC4, but does do 3DES.
I started a scan of Alexa's top 1 million websites. It's going to take a few
days to have all the results.
So far,
On Thu, Jan 09, 2014 at 12:59:40PM -0500, Julien Vehent wrote:
I started a scan of Alexa's top 1 million websites. It's going to
take a few days to have all the results.
So far, 21 out of 1396 websites scanned support neither AES or 3DES.
I'm about half way through the scan, but it's unlikely
On 2014-01-27 17:22, cl...@jhcloos.com wrote:
In case anyone is keeping a list, while helping a relative I determined
that timewarnercable.com's login server (wayfarer.timewarnercable.com)
will not work with tls 1.1 or 1.2. The connection fails after the client
right after the client hello.
On 2014-03-23 11:43, gegard4321 wrote:
Another reason to enable DHE_RSA_AES_*_GCM: Mozilla's new account
system only
supports RSA and DHE_RSA ciphers:
https://www.ssllabs.com/ssltest/analyze.html?d=accounts.firefox.com
Same goes for mozilla.org and bugzilla.
On the server side, we are working
On 2014-10-21 19:20, Julien Pierre wrote:
I wasn't even specifically referring to cipher strings, but the whole
document seems to be about servers running OpenSSL, though I did see
a
few references to GnuTLS as well.
There are also servers running NSS, Microsoft SSL stacks, proprietary
SSL
On 2014-10-22 08:02, Hubert Kario wrote:
So, any comments to the proposed changes in opening mail?
Yes :) But I haven't had any spare cycles yet... It's on the todo list!
- Julien
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
Thank you Hubert from starting this discussion. I think this can be the
base for version 4 of the document.
On 2014-10-20 08:10, Hubert Kario wrote:
The items that probably should be changed or added:
* curves weaker than secp256r1 - I think they shouldn't be
enabled at all - while
It may be best to report it on bugzilla. That link should go to the
right component:
On 2015-11-30 12:47, Robert Relyea wrote:
I've always found the 128 bit prioritized over 256 a silly
recommendation, I support reordering.
Can you expand on why you think it is silly?
The original thread [1] had a long discussion on this topic. The DJB
batch attack redefines the landscape,
:
$
LD_LIBRARY_PATH=/home/ulfr/src/hg.mozilla.org/firefox/obj-x86_64-pc-linux-gnu/config/external/sqlite/
\
/home/ulfr/src/hg.mozilla.org/firefox/obj-x86_64-pc-linux-gnu/dist/bin/signmar
-d . -n testmar -v /tmp/resigned.mar
$ echo $?
0
- Julien
On Tue 19.Jun'18 at 8:50:46 -0400, Julien Vehent
Hi everyone,
I'm reimplementing Firefox MAR signature and would like to verify those
signatures with signmar. Signmar uses NSS on Linux, and I'm running into
issues getting it to work. Below are the steps to reproduce:
Take a signed MAR file from https://ulfr.io/f/resigned.mar and a public
RSA
25 matches
Mail list logo
