@ericlaw Probably PSS and your decoder hasn't been updated for 1.3? The codepoints are no longer decomposed into hash/sig tuples as that's not how signature schemes work in general.
@ericlaw TLS 1.2 changed a bunch of them too, to add the signature algorithm. Anything after ClientHello and bits of ServerHello has always been version-specific and fair game to change.
@h4kr@BruceDawson0xB That guidance always worried me. Asking devs to think about worst case bounds on every map feels akin to thinking about whether some missed check is exploitable. Much lower stakes, but still a bit error-prone of a default for my comfort.
@taviso@GuidoVranken Different reuse there, but yeah X509's setters basically don't work. Except you need to setters to issue certs, so it's a mess. No idea whether anyone actually relies on this particular case. I just reviewed the diff and noticed it broke something they previously had code for.
@BRIAN_____ It also catched bugs. We learned as a result that a few projects imported RSA keys wrong and swapped p and q! They just never noticed because CRT would always fail and then fallback in OpenSSL, making RSA signing unnecessarily slow.
@DrawsMiguel@shafikyaghmour I want a strict aliasing sanitizer, less to check my code (though that too) but really to demonstrate that no real world C code actually follows that rule.
@BRIAN_____@djco@FiloSottile The spec reference in the bug is wrong; ClientHello.legacy_version is not the same as the record layer version.
And yeah I doubt that is the issue. The record layer version is totally meaningless and vestigial.
@hanno@buherator@agl__ Thanks to that mess, it takes more bytes to encode RSA-PSS *parameters* in X.509 than to encode an entire ECDSA signature. PSS is singlehandedly the reason X.509 signature algorithms aren't a plain enum.
@FiloSottile@taviso@GuidoVranken Whether it's a bug in ModSqrt is up to interpretation. Tonelli-Shanks ultimately only works for primes. Always terminating is prudent. But accepting random attacker-supplied coefficients is a bad idea and forbidden by RFC5480. IMO that's the root bug, which doesn't affect Go.
@bascule@SchmiegSophie@cryptodavidw@cronokirby Malleability of (r, s) aside, parsing ECDSA signatures with DER should be perfectly compatible with real world TLS. Our implementation is strict, and OpenSSL hasn't accepted invalid DER here since 2015.
@ericlaw@sleevi_ It is usually what I do. The formats are... just barely boring enough to for it to be bearable. I meant to write a tool, but I really wanted it be reversible (like der-ascii). Working out a design I liked took more time than I had available.
@RichSalz @sleevi_@bascule@cwallace_bass I still don't even know how to read the new syntax! I can guess at it, but I've yet to have to learn it properly.
@sleevi_@bascule For DER, the type alone determines constructedness, so you can kinda pretend it's part of the tag, even if it technically isn't. BER has this awful constructed strings encoding, so some types might be either in BER.
@sleevi_@bascule Put another way: constructed is a property of the value, not the tag. It tells you whether the value is more TLVs or some random leaf element. So EXPLICIT is always constructed (wraps another TLV). IMPLICIT replaces the tag, so its constructed bit is based on the inner element.
I look forward to all the latent X.509 bugs around 2050, as we rollover from UTCTime to GeneralizedTime.
Did you think we were done with two-digit years after Y2K? Well, X.509 has some news for you!
@__phantomderp @strega_nil @DrawsMiguel https://t.co/gyfjpNK1Fo is the memcpy language bug. That one is bad enough that we had to add wrapper functions for memcpy because constantly worrying about whether a slice could be empty is not reasonable.
@__phantomderp @strega_nil @DrawsMiguel Fixing NULL + 0 would also be good. Both it and the memcpy(NULL, 0) language bug affected real world code in BoringSSL. If you have a function that takes ptr,len, NULL,0 is the natural way to say empty slice. But C is full of unnecessary places that break when you do that.
@RichSalz Well, AES is still significant progress. For GHASH, BearSSL has a writeup of a very neat strategy. I have some code I can contribute there if interested.