Re: [openssl-dev] Future of custom extension API?

On Mon, Nov 14, 2016 at 7:00 AM, Salz, Rich wrote: > > What are the chances that the OpenSSL devs would be interested in > upgrading this API? > > Pretty good. > > We’re looking at adding a new API for 1.1.1 that is like the one in boring > -- it gives full acess to the hello

[openssl-dev] Future of custom extension API?

Hi, folks. I am a big fan of the concept of the custom extension API, but it needs a bit of work. If it were a bit more usable, I think we could move a lot of simple extensions into this framework, simplifying OpenSSL. In particular, I feel that managing complexity in OpenSSL is the single

Re: [openssl-dev] Enhancing ssltest_old.c?

upgrade similar to my PR, while working out what an improved custom extension API should look llike? Bill On Mon, Sep 5, 2016 at 7:12 PM, Bill Cox <waywardg...@gmail.com> wrote: > I took a quick look through the new SSL test framework, which looks pretty > good. I created this

Re: [openssl-dev] Enhancing ssltest_old.c?

framework... > > Cheers > Richard > > Bill Cox <waywardg...@gmail.com> skrev: (5 september 2016 19:14:22 CEST) > >I wrote a simple change to custom extensions so that they can be > >negotiated > >on resume, which is needed by token binding. I put the test for this &g

[openssl-dev] Enhancing ssltest_old.c?

I wrote a simple change to custom extensions so that they can be negotiated on resume, which is needed by token binding. I put the test for this change in test/ssltest_old.c, which seems weird, but there are no custom extension tests in the new SSL tests AFAIK. Do we still extend the old tests

[openssl-dev] Low priority feature request: EVP_SIG object

This is low priority, IMO, but it would help with my current task. I happen to be updating my token binding library at work to use the new more compact HTTP headers. We write the X, Y, R, and S values, length-prefixed, for ECDSA-P256, and the modulus and exponent for RSA. My previous code uses

[openssl-dev] Token binding as a custom extension

Hi. I implemented the token binding TLS negotiation extension in BoringSSL using the OpenSSL custom extension API. AFAIK, there are no current examples of any custom extensions in the OpenSSL code base. Is this correct? While my ulterior motive is to promote token binding (Google pays me to

[openssl-dev] [openssl.org #4254] PR for BLAKE2 support

This PR is on github at: https://github.com/openssl/openssl/pull/566 This set of changes adds initial BLAKE2 support to OpenSSL. The BLAKE2s is a 32-bit friendly 256-bit hash, while BLAKE2d is a 64-bit friendly 512-bit hash. The point of BLAKE2 is extremely fast secure hashing, even faster than

Re: [openssl-dev] Minor bug in custom TLS extensions

On Wed, Sep 2, 2015 at 7:55 AM, Matt Caswell <m...@openssl.org> wrote: > > > On 02/09/15 15:50, Bill Cox wrote: > > As for the order issue, we parse headers before creating any, so I'll > > just not add the header in the AddCallback if s->hit is set on the > &

[openssl-dev] Minor bug in custom TLS extensions

This seems like a bug to me: /* * If this ClientHello extension was unhandled and this is a * nonresumed connection, check whether the extension is a custom * TLS Extension (has a custom_srv_ext_record), and if so call the * callback and record the

Re: [openssl-dev] common factors in (p-1) and (q-1)

On Fri, Jul 31, 2015 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL u...@ll.mit.edu wrote: I think adding the recommended check would be beneficial. Considering the frequency of ‎key generation, performance impact shouldn't matter all that much. Samuel's argument above is one I've heard before

Re: [openssl-dev] common factors in (p-1) and (q-1)

Cool observation. From running a bit of Python code, it looks like the probability that GCD(p-1, p-q) == 4 is a bit higher than 15%, at least for random numbers between 2048 and 4096 bits long. It looks like putting in a GCD(p-1, q-1) check will slow down finding suitable p and q by around a

Re: [openssl-dev] common factors in (p-1) and (q-1)

On Fri, Jul 31, 2015 at 12:35 PM, mancha manc...@zoho.com wrote: If so, here's my quick dirty back-of-envelope calculation (mod bound) for the probability the gcd of two randomly chosen integers x,y is at most k: k p(gcd(x,y)=k) - -- 1 60.79% 2 75.99%

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

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:

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

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

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

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

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

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

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

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.