done.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3897
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
The status of the draft is unchanged (Finding Reviewers). Perhaps OpenSSL
can speed up the review process.
BLAKE2 has a keyed (aka MAC/PRF) mode, so it may also replace Poly1305. A
BLAKE2 MAC can be customized wrt key or tag size, and can provide the
highest security level for a give key/tag size
That shouldn’t be too difficult (finding reviewers, I mean).
Is the ISE asking for volunteers to review? What kind of volunteers? IMO what
a reviewer needs to be able to say is:
- The document is clear (you can implement based on this)
- The algorithm might be useful in the IETF
- The
Actually, just to get the ball rolling, I'll integrate the reg version of
Blake2, which is portable C, and a bit faster than the reference version,
which was designed for readability rather than performance.
___
openssl-dev mailing list
To unsubscribe:
On Jun 11, 2015, at 2:36 AM, Bill Cox waywardg...@google.com wrote:
BLAKE2 rocks. I'm looking forward to using it in many applications.
Sure. I would be glad to see that used as a hash in signatures and in TLS, as a
PRF in TLS and IKE, etc.
Does anyone know what the status of
On Tuesday 09 June 2015 10:20:47 Bill Cox wrote:
On Tue, Jun 9, 2015 at 9:57 AM, Rainer Jung rainer.j...@kippdata.de wrote:
Not an expert here, but according to
https://131002.net/blake/
and
http://en.wikipedia.org/wiki/BLAKE_%28hash_function%29
the terms BLAKE-256 and
On Tue, Jun 9, 2015 at 10:00 PM, Bill Cox waywardg...@google.com wrote:
I would suggest that we move ahead with the last option — the
reference implementation of BLAKE2sp.
I have trouble agreeing with this. First, BLAKE2sp is more than 10X slower
than BLAKE2s for 256 bit inputs on my
On 11-06-2015 00:36, Bill Cox wrote:
Samuel Neves' SSE version is the one we all played with in the Password
Hashing Competition. The speed is amazing. Is there a faster version
available now? Which version should we integrate into OpenSSL?
The problem with my implementation is that it
On Wed, Jun 10, 2015 at 8:45 PM, Salz, Rich rs...@akamai.com wrote:
Of course, we can take a known-good compilation output and place the
assembly directly into the library. Andrew Moon's
That's not the way openssl works with assembler. I expect that anything
other than the perl-based
Of course, we can take a known-good compilation output and place the assembly
directly into the library. Andrew Moon's
That's not the way openssl works with assembler. I expect that anything other
than the perl-based assembler stuff will get pushback from our assembler guru.
Zooko only asked for supporting Blake2 as an MD5 replacement, but he's being
too modest. I can't stress enough how important the speed of Blake2
The problem is that when you say Blake2 everyone (yes, everyone in the entire
world:) thinks it's one digest. What's really meant is a family of
I agree. How about Blake256 and Blake512, and leave out the parallel
versions? That's not confusing.
My original proposal :)
I don't think supporting some of the Blake family is in any doubt.
___
openssl-dev mailing list
To unsubscribe:
On Tue, Jun 09, 2015 at 12:19:56AM +, Zooko Wilcox-OHearn wrote:
I'd support adding 2b and 2s, in spite of the fact that the names are
really really bad. I'm less interested in seeing the parallel variants
added. FWIW.
Well, the reason I'm here is that the GNU coreutils
On Tue, Jun 09, 2015 at 12:19:56AM +, Zooko Wilcox-OHearn wrote:
I'd support adding 2b and 2s, in spite of the fact that the names are
really really bad. I'm less interested in seeing the parallel variants
added. FWIW.
Well, the reason I'm here is that the GNU coreutils
Am 09.06.2015 um 18:43 schrieb Bill Cox:
On Tue, Jun 9, 2015 at 9:38 AM, Salz, Rich rs...@akamai.com
mailto:rs...@akamai.com wrote:
Zooko only asked for supporting Blake2 as an MD5 replacement, but he's
being too modest. I can't stress enough how important the speed of Blake2
The
On Fri, Jun 05, 2015 at 04:39:36PM +, Zooko Wilcox-OHearn via RT wrote:
We, the BLAKE2 maintainers, offer both reference C code and optimized
implementations: https://blake2.net/#dl . There are also other
implementations with various virtues available: https://blake2.net/#sw
So it's my
All of these are good options in my opinion:
BLAKE2b — widely used, very efficient on modern 64-bit Intel CPUs and
on ARM chips with NEON, simpler than the p versions
BLAKE2s — more efficient on 32-bit chips (e.g. ARMs) which do *not* have NEON
BLAKE2sp, multithreaded — fastest option on
Hi Bill,
First of all, it's spelled BLAKE, with capitals :-)
BLAKE-256 is the 256-bit version of BLAKE. Calling BLAKE2 BLAKE would be
confusing.
What about B2-256 and B2-512?
ccing other B2 codesigners
On Tue 9 Jun 2015 at 19:20 Bill Cox waywardg...@google.com wrote:
On Tue, Jun 9, 2015 at
Dear Kurt:
Another option is to include BLAKE2sp but use the single-threaded
reference implementation of BLAKE2sp. (Thanks to Samuel Neves for
reminding me about this.)
That way the hash values produced would be compatible with other
people's implementations, or possible future implementations,
Bill, I agree.
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Bill Cox
Sent: Tuesday, June 9, 2015 18:00
To: openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
function (let's kill
On Tue, Jun 9, 2015 at 11:13 AM, Zooko Wilcox-OHearn
zo...@leastauthority.com wrote:
All of these are good options in my opinion:
BLAKE2b — widely used, very efficient on modern 64-bit Intel CPUs and
on ARM chips with NEON, simpler than the p versions
BLAKE2s — more efficient on
On Fri, Jun 05, 2015 at 04:39:36PM +, Zooko Wilcox-OHearn via RT wrote:
One of the coreutils maintainers suggested that we should ask OpenSSL
to add BLAKE2, because coreutils itself will probably just use a
portable C implementation, but it would use an optimized
implementation if
I'd support adding 2b and 2s, in spite of the fact that the names are really
really bad. I'm less interested in seeing the parallel variants added. FWIW.
Well, the reason I'm here is that the GNU coreutils maintainers rely
on openssl for high-performance crypto, and blake2sp might be the
(re-sent because I wasn't subscribed to openssl-dev first time and it
bounced from there but went through to rt@.)
Dear Rich Salz et al.:
b is for big — fits well with 64-bit architectures, and s is for
small — fits well with 32-bit architectures.
p is for parallel — has several parallel
(re-sent because I wasn't subscribed to openssl-dev first time and it
bounced from there but went through to rt@.)
Dear Rich Salz et al.:
b is for big — fits well with 64-bit architectures, and s is for
small — fits well with 32-bit architectures.
p is for parallel — has several parallel
So if you're going to replace md5sum... which one should you use? Which ONE
HASH should replace MD5?
Or why not just use sha256 and sha512.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Blake2s is 256-bit, while Blake2d is 512-bit. These are the ones I assume
that would be best for addition. The other two, Blake2sp and Blake2bp are
multi-threaded, and are optimized for multi-core CPUs.
It is unfortunate that 's' and 'd' mean different algorithms, while 2sp and 2bp
are,
Dear Rich Salz et al.:
b is for big — fits well with 64-bit architectures, and s is for
small — fits well with 32-bit architectures.
p is for parallel — has several parallel threads that each compute
the hash of a different subset of the input data, and then those
hashes get hashed together to
I'd support adding 2b and 2s, in spite of the fact that the names are really
really bad. I'm less interested in seeing the parallel variants added. FWIW.
Well, the reason I'm here is that the GNU coreutils maintainers rely
on openssl for high-performance crypto, and blake2sp might be the
On Tue, Jun 9, 2015 at 12:57 AM, Salz, Rich rs...@akamai.com wrote:
So if you're going to replace md5sum... which one should you use? Which ONE
HASH should replace MD5?
I'd suggest blake2sp. It's currently the fastest on my machine, and I
guess that there will often be multiple cores in
I could be wrong, but I did not see any assembler. SIMD is done with
standard Intel macros.
Hooking up looks simple to me. So you need a volunteer? I've been poking
around the code lately.
On Jun 8, 2015 4:11 PM, Salz, Rich rs...@akamai.com wrote:
Anyway, I think we should add it.
I am in
If the goal is replace md5sum, then one thing to think about is which digest
will have the widest reach for everyone? Can all four versions be
implemented in (mostly?) portable C code? Is performance the only real
difference? Suppose we took just blake2s?
All four are available in
Anyway, I think we should add it.
I am in favor of doing that, too. But there's some work that needs to be done:
hooking it up to the EVP API, and tweaking the assembler stuff to use our
perl-based structure, right?
___
openssl-dev mailing list
To
So it's really a request to add four hash functions. Bummer.
In practice the parallel mode works nicely on modern systems.
Well, on clients. On servers, presumably, those cores would be busy ;)
I'd support adding 2b and 2s, in spite of the fact that the names are really
really bad. I'm
Well, the reason I'm here is that the GNU coreutils maintainers rely on
openssl for high-performance crypto, and blake2sp might be the best
algorithm for the new b2sum tool, which I hope will replace md5sum
in the toolboxes of system administrators everywhere.
Yes, I went and read the thread
On Jun 9, 2015, at 4:07 AM, Zooko Wilcox-OHearn zo...@leastauthority.com
wrote:
On Tue, Jun 9, 2015 at 12:57 AM, Salz, Rich rs...@akamai.com wrote:
So if you're going to replace md5sum... which one should you use? Which ONE
HASH should replace MD5?
I'd suggest blake2sp. It's
On Friday 05 June 2015 16:39:36 Zooko Wilcox-OHearn via RT wrote:
Dear OpenSSL folks:
I'm one of the authors of the BLAKE2 hash function
(https://blake2.net). I've been working with the maintainers of GNU
coreutils to make a tool named b2sum, which I hope will eventually
replace md5sum.
On Jun 8, 2015, at 1:37 PM, Hubert Kario via RT r...@openssl.org wrote:
On Friday 05 June 2015 16:39:36 Zooko Wilcox-OHearn via RT wrote:
Dear OpenSSL folks:
I'm one of the authors of the BLAKE2 hash function
(https://blake2.net). I've been working with the maintainers of GNU
coreutils
On Jun 8, 2015, at 1:37 PM, Hubert Kario via RT r...@openssl.org wrote:
On Friday 05 June 2015 16:39:36 Zooko Wilcox-OHearn via RT wrote:
Dear OpenSSL folks:
I'm one of the authors of the BLAKE2 hash function
(https://blake2.net). I've been working with the maintainers of GNU
coreutils
Not that my opinion here counts, but I'll second the call for BLAKE2
support. The SIMD implementation is one of the finest works of efficient
cryptographic code I've run across. It's so efficient, it became by far
the most popular hash function in the Password Hashing Competition. BLAKE2
rocks.
Dear OpenSSL folks:
I'm one of the authors of the BLAKE2 hash function
(https://blake2.net). I've been working with the maintainers of GNU
coreutils to make a tool named b2sum, which I hope will eventually
replace md5sum.
md5sum is the most widely-used tool in the world for data integrity
but,
41 matches
Mail list logo
