BearSSL – Smaller SSL/TLS(bearssl.org) |
BearSSL – Smaller SSL/TLS(bearssl.org) |
> No dynamic allocation whatsoever. There is not a single malloc() call in all the library. In fact, the whole of BearSSL requires only memcpy(), memmove(), memcmp() and strlen() from the underlying C library. This makes it utterly portable even in the most special, OS-less situations. (On “big” systems, BearSSL will automatically use a couple more system calls to access the OS-provided clock and random number generator.)
> On big desktop and server OS, this feature still offers an interesting characteristic: immunity to memory leaks and memory-based DoS attacks. Outsiders cannot make BearSSL allocate megabytes of RAM since BearSSL does not actually know how to allocate RAM at all.
Edit: Just discovered what makes this an even more interesting one to watch, it's the work of this Wizard: http://security.stackexchange.com/users/655/thomas-pornin
No, they world needs as many of those as it can get (if they are tagged as such). And then all the authors need to discuss with each other what they learned from the implementation. And then they compare their code with existing code bases and discuss differences. They review their patches, as well as patches from other projects.
They discuss the diffs, learn from others and bring in new ways too look at things.
All bugs are shallow given enough eyes, and yet one of our biggest mantra's sole purpose is to limit the number of eyes. We need people that are familiar with crypto codebases and its subtleties, because we need the reviewers for our established projects. And for this reason, we need people to write and publish crypto related code. Not so we can push another new, excitingly half-baked TLS stacks into a product, but to foster the code review process we all rely on.
Are you saying we should live forever with the established SSL libraries?
The only way software can mature, is to write it, release it, ship it, fix it, repeat.
Completely unrelated but:
Another small footprint ssl/tls library, very readable code and a pleasure to work with.
EDIT: Thanks for the sincere responses. In retrospect my question might have appeared smarmy, but that wasn't my intent and I really appreciate the responses.
• Security
• The server you speak with requires SSL
Reasons for no general purpose OS:
• Limited power (battery, solar)
• Extreme cost pressures (linux needs about $5 of hardware)
• Security (smaller code to audit)
• Extreme reliability requirements
So anything that ticks a bullet in each category is a candidate.
• Remote sensors
• Radio gateway, say LoRa to an internet server
• A device which keeps a secret for you and provides it to a server on command, perhaps something in a 2FA vein.
• Remotely triggerable actuators (door locks, parking lot lights)
Many automotive or industrial communication buses are currently unencrypted, but could surely benefit from encryption.
Here's an interesting thought: you don't become mature without starting somewhere.
Malloc is potentially troublesome for two reasons. First, its performance is potentially unpredictable. It depends on the current state of the heap at the time of the call, which you can't know in advance except in some very rare situations. It can also fail entirely, and that is likewise unpredictable.
memcpy and memmove, ultimately being byte-copying loops, don't suffer from these problems. Their performance is consistent and they always succeed if your pointers and lengths are valid.
On PCs these days, the troubles of malloc don't matter much. You have so much performance margin that occasional slow calls don't matter, and virtual memory with a big address space means that it almost never fails. If it does fail, it's OK if the program crashes and you have to restart it. But many systems are much more constrained.
I'm personally really excited for this: https://github.com/briansmith/ring
It's a Rust oxidization of the BoringSSL library, meaning that parts of BoringSSL are being rewritten in Rust, with the eventual goal of being pure Rust.
No, being pure Rust is not the goal. It aims to use Rust as much as possible for the parts that Rust is good at. But core crypto algorithms generally need to be written in assembler, to avoid various timing attacks that could be introduced by optimization. And for things that would require large amounts of `unsafe` in Rust, there's less reason to port that to Rust, and leaving it in C can be more clear.
See the style guidelines from the project:
https://github.com/briansmith/ring/blob/master/STYLE.md#unsa...
The thing that are most appropriate for Rust are parsing, protocol implementation, higher level code that uses core crypto primitives, and providing a safe API to client code. But the core crypto primitives themselves will remain written in C and/or assembler, as appropriate.
Assembler only goes so far. Until you figure out how the processor's front end will decode the machine code and run the underlying RISC program, or how the hypervisor will schedule your program on some shared machines (e.g. in EC2) you're susceptible to a different class of side-channel attacks.
So while there are excellent examples of C projects out there, there are many more that show why it's important to provide developers (even the good ones) with guard rails.
But: Thomas Pornin!
So, this is pretty neat. I hope lots of crypto people take a very hard look at it.
I don't know the guy but, from what I gather, he is considered to one of these experts, yes?
(Edit: If I would have read further comments before replying, I would've found the answer to my question.)
Therefore the proposed bug squashing strategy of "just claim that there's a bug in XYZ and let him oracle what it is".
followed by:
"TLS 1.0, TLS 1.1 and TLS 1.2 are supported", "3DES/CBC encryption algorithms are supported", and "SHA-1 [is supported]"
Sad-face.
These algorithms should obviously only be used in fallback to stronger ones but they are not broken to the point where they should never be used as SSL3, RC4, and MD5 have been.
You can't drop all of these things and end up with something generally useful.
My point is about the imprecise description.
Makes me suspect that a major goal is anonymity. It's less aimed at users installing on their non-anonymous Windows/Mac/phone but rather leverage generic/commodity hardware to communicate over SSL. Throwaway burner phones.
Considering the recent events around IoT having good crypto libraries for that seems like it could be useful.
https://github.com/SuperHouse/esp-open-rtos/blob/master/exam...
I think it's great when people write something for the love of it.
For a high quality TLS implementation that is production-ready, and has had extensive third-party verification and certification, I'd recommend mbedTLS from ARM.
This trainwreck of an API is the opposite of what we want: https://gnutls.org/reference/gnutls-gnutls.html
It would probably be faster to write your own TLS library than learn all of that.
OpenSSL doesn't fare much better. So far, libtls looks the most promising. But last I checked, it was still a bit too spartan and couldn't operate in non-blocking mode, which kills you if you want an event-driven server.
I thought it was a play on 'bare' - e.g. only the basic features needed.
Thanks, we definitely need a secure and reputable TLS implementation with small footprint for IoT devices.
[invalid issue removed]
The author could have easily continued with their trend of using alternative languages and ended up with something just as unique. UrsidSSL, BhaalooSSL, XiongSSL; all could have continued the trend without coming across as a sly attack.
It's not as if wolfSSL is a new kid on the block in the world of embedded SSL.
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.
I intend to write (in many details) how the whole thing is designed. Give me a couple of months.
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?)
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.
Disregard me.
The idea that no one should ever roll their own cryptography is a cutesey warning for amateurs, but not an absolute rule. If no one ever did, we would never have any.
Also projects like openssl don't have third-party quarterly audits or other formal practices. They're "rolling their own" as much as the other guy.
But generally, "says who" is answerable as "says any reputable applied cryptographer, established audit/research team, etc. who's thoroughly cut their teeth on crypto and security in general."
And 3DES?
A clean, simple to use, or rather hard-to-use-in-a-wrong-way API is very much needed (and there are some libraries that are nice to use but not very proven).
Generally, open source software benefits from more users. But having a huge amount of users makes it more difficult to improve and cleanup because you can't just deprecate stuff easily. (like SSL2/3).
Also, having 100% of the internet using openssl makes the impact of a vulnerability in that library huge. Some diversity is probably a good thing.
I appreciate the time and effort that you are putting into it, good luck.
author Thomas Pornin
AES (Advanced Encryption Standard, 1997 to 2000): co-author of the block cipher DFC
eSTREAM (ECRYPT Stream Cipher Project, 2004 to 2008): co-author of the stream cipher SOSEMANUK (admitted in the final portfolio)
SHA-3 (2007 to 2012): co-author of the cryptographic hash function Shabal (selected for second round)
PHC (Password Hashing Competition, 2013 to 2015): author of the password hashing function Makwa (finalist, was awarded a "special recognition")
Author of the sphlib library: optimized implementations of many cryptographic hash functions, both in C and Java.
Author of RFC 6979: Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA).
As alpha software, I'd be shocked if anyone was using it in a production capacity, but it could be useful for early investigations into issues like timing attacks - clearly, it's better to get them sorted before a "final" release. I'd hope that any project planning to adopt this or any) crypto code was first getting it analysed carefully.
On the other hand, quite a bit of existing crypto is there because it was the first implementation on a given platform, despite potentially having issues - think about heartbleed, which was missed for quite a while in very heavily used software. It's not always bad to have fresh alternatives, as long as they are approached cautiously.
The reason is that there are subtle attacks on the implementation, such as timing attacks, which can leak information.
Given a choice between building something with Nacl and a bespoke stream cipher and building something with a bespoke cryptosystem and AES, I would have a hard time picking, but I'd lean towards Nacl.
Use proven and battle tested library. You won't do any better on your own.
If this is to be a general library that validates the entire certificate chain, then you'll need SHA-1.
Now if the library tries to advertise SHA1 in ServerHello by default, then that is indeed unfortunate.
Using char pointers presumably is to get correct aliasing analysis?
If your goal is to truly improve the state of the art in the ecosystem, dropping anything that is even remotely insecure is appealing I get that and I do believe the people behind BearSSL would love to do that. However to truly improve anything you need two things: Popularity and improve security.
There is a conflict there because popularity requires, at least some, compatibility to what already exists. You need to balance out security and compatibility. I think there is room for discussion about where precisely that balance is. You could further tilt it towards security by helping users of the library get a sense of what they need to support. Ultimately though you can't just blindly drop everything that's somehow not perfectly secure. Doing so would not improve security at all.
It's a small sacrifice to have one library be a little bit less secure than it could be, if that helps to make everything more secure it all.
Little doubt that someone would find it useful, but it is An Undertaking, to preserve something which is not that desirable.
(that can take many forms, but that general idea is how most software updates currently work)
wohaa. what?
wow. an opportunity for me to use google. if you are actually serious?
edit:lol my phone default searches to bing... didn't find anything about ruby on rails being banned in canada.
Yes, EdDSA is faster, with 64 byte signatures. Recommended.
1. Hashing the incoming data
2. Decrypting an attached signature
3. Verifying the decrypted and calculated hash are the same
Even though Step 2 would involve RSA or ECC, wouldn't Step 1 be the most expensive part regardless?
But no, judging from the code, you just give it one big fat I/O buffer that will usually come from .bss
It does eliminate a certain couple classes of errors, and makes some others less likely.
I didn't read all the code, but I don't think it's using alloca or the like. So the stack allocation sizes are known at compile time, and bounded unless there's some recursion going on (which is unlikely).
Note that this is not very practical, and impractical crypto is almost as good as no crypto.
I'm not advocating everyone and their mother implement their own crypto. But some software diversity is a good thing. These algorithms aren't quite as scary or fickle as the documentation and existing implementations make them seem. Especially if you stick to good software like DJB's stuff.
For instance, using montgomery/edwards curves instead of weierstrass curves eliminates a lot of the difficulty in writing a constant-time implementation of ECC. And the 25519 implementation comes with a fast, constant-time implementation of a prime field type.
Yet even DJB's stuff can be simplified. You can knock off a good 80% of the scary code at a cost of a mere 10% of performance. To Google or Facebook, that may be unacceptable. But to me, that's entirely worth it. Now you have a tiny library that is easy to understand, and easy to audit.
Wouldn't you say DJB (et al) did that themselves? https://tweetnacl.cr.yp.to/
Compare theirs: https://tweetnacl.cr.yp.to/20140427/tweetnacl.c
To mine:
https://gitlab.com/higan/higan/blob/master/nall/elliptic-cur...
https://gitlab.com/higan/higan/blob/master/nall/elliptic-cur...
https://gitlab.com/higan/higan/blob/master/nall/cipher/chach...
https://gitlab.com/higan/higan/blob/master/nall/mac/poly1305...
https://gitlab.com/higan/higan/blob/master/nall/hash/sha256....
Please note that like BearSSL, my implementations are alpha-quality. Further, I'm not suggesting anyone use these in production. If I do so myself and it blows up in my face, it'll only have harmed me, and I'll only have myself to blame.
(Also, I'm really bad when it comes to source code comments, sorry. The why really needs you to read the research papers; the how is mostly self-evident. The remaining one-letter variable names were used to match the papers, and because I couldn't think of more descriptive terms.)
they have all code running in constant time from the alpha version.
Next comes making sure there are no buffer overflows. the code is stable and compatible.
If everyone leaves it to someone else who does it exactly?
Obviously not ready for use in production until its been audited.
Remind me again where i can download an audited ssl implimentation?
Not sure I'd agree with that. OpenSSL is very far from perfect and obviously contains many many security bugs, but it also has a very long history of fixes, knowledge, etc. and has a large number of eyes on it. It's more of a known quantity than something new.
There is not a single malloc() call in all the library. In fact, the whole of BearSSL requires only memcpy(), memmove(), memcmp() and strlen() from the underlying C library. This makes it utterly portable even in the most special, OS-less situations. (On “big” systems, BearSSL will automatically use a couple more system calls to access the OS-provided clock and random number generator.)
On big desktop and server OS, this feature still offers an interesting characteristic: immunity to memory leaks and memory-based DoS attacks. Outsiders cannot make BearSSL allocate megabytes of RAM since BearSSL does not actually know how to allocate RAM at all.
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
It's just full with con-/de-structor noise and don't even get me started with virtual function calls.