On Tue, 2018-01-16 at 14:50 +, Salz, Rich via openssl-dev wrote:
> OpenSSL defines it as a SET OF and the spec says it’s a SEQUENCE
> OF. Ouch! Will that cause interop problems if we change it? (I
> don’t remember the DER encoding rules)
>
>
>
Well, a SEQUENCE uses tag 16 while a SET
After noticing that a safecontents bag written to a file was in a
different order than I added them, I did some experimentation and
discovered that it's sorting the list, which led me to notice that it's
defining a safecontentsbag as a SET OF safecontents, which causes
sorting:
With a small number of buckets, it seems to me that no hash algo will
make you safe from a flooding attack. You can simply generate your
hashes locally using whichever algo the server uses, and only send those
that fit into your attack scheme. The data could even be pre-generated.
The only way
Just a note from my own experience way back when: I tried hashing using
various algos and measuring bucket use as the main comparison criteria.
I found that the crypto hashes left a fair number of unused buckets. Of
course, CRCs were far worse. What gave the most normal distribution was
to
On Thu, 2016-03-24 at 01:08 -0400, Jeffrey Walton wrote:
Lack of relevance. C++ is NOT C. There many subtle and not so subtle
differences. OpenSSL is written in C. Use a C compiler.
'make -k' is telling me its a little more than (ir)relevance. I see
some stuff going on that's not allowed
On Tue, 2015-11-17 at 00:01 +, Viktor Dukhovni wrote:
On Mon, Nov 16, 2015 at 11:23:52PM +, Matt Caswell wrote:
Disabling algorithms isn't the right answer IMO. I do like the idea of a
"liblegacycrypto". That way people that only have need of current
up-to-date crypto can stick with
> > On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> > > FWIW I checked a couple of TLS implementations I have around (GnuTLS
> > > and s2n), and AFAICT they don't check for a maximum size at all.
> >
> > what do you mean by that? As we've said with Matt, you can't create a
