News for hackers. Stuff that matters.
Re:BearSSL – Smaller SSL/TLS by unwind on Thursday November 03, 2016 @10:25AM (#12864145)
This sounded very interesting.

However, it seems it's been developed "in secret" and the only public commit is a huge import of all of it. :/

Too bad, the development history would have been very interesting to read, digesting it all at once is harder.

Re:BearSSL – Smaller SSL/TLS by pornin on Thursday November 03, 2016 @10:32AM (#12864202)
Honestly, all my internal git commit messages are "...".

I intend to write (in many details) how the whole thing is designed. Give me a couple of months.

Re:BearSSL – Smaller SSL/TLS by pfalcon on Thursday November 17, 2016 @02:27AM (#12975182)
> Honestly, all my internal git commit messages are "...".

Very insightful about how security experts write security code, thanks! All that documentation which you hope to write some time - half of it should have been in your commit messages (that's what they teach on StackOverflow, no?)

Re:BearSSL – Smaller SSL/TLS by unwind on Thursday November 03, 2016 @10:49AM (#12864371)
Okay, that explains it, anyway. :)

I have absolutely nothing to say when it comes to crypto, but as a C dork I found it ... quirky that the encoding/decoding functions in inner.h (https://bearssl.org/gitweb/?p=BearSSL;a=blob;f=src/inner.h;h...) seem to use e.g. uint32_t to get a 32-bit type, while assuming that char is 8 bits (rather than using uint8_t). This seems strange.

Re:BearSSL – Smaller SSL/TLS by zAy0LfpBZLC8mAC on Thursday November 03, 2016 @11:51AM (#12865021)
I don't think it assumes it's 8 bits, but rather it assumes the values won't be outside the range of an 8 bit number, which should be fine, given that it's an octet-oriented protocol?

Using char pointers presumably is to get correct aliasing analysis?