28 ms·
BearSSL – Smaller SSL/TLS
- rdeboo 10y agoOne of the cliches about crypto is that you should not implement your own crypto. Not to suggest that the authors don't know what they are doing, but they mention 'alpha' quality themselves on the site. I wonder, how long does it take until a new library is deemed secure? What does the process look like? Trial and error? Or do they compare notes with vulnerabilities found in e.g. openssl?
- lexman0 10y agoGenerally the cliche is about not implementing your own cryptographic algorithms. As long as they only implement existing algorithms and don't generate new ones, I don't think this applies.
- rdeboo 10y agoI used to think that; but I'm following Dan Boneh's crypto course on Coursera at the moment, and he specifically notes that you should not even try to implement known algorithms yourself (for production; you could do it ofcourse for the learning experience). The reason is that there are subtle attacks on the implementation, such as timing attacks, which can leak information.
- pornin 10y agoOne of the point of the exercise is to provide constant-time implementations that provably do not leak such information. The hash functions, two AES, one DES/3DES, RSA and elliptic curve implementations in BearSSL have been written to be constant-time. I still have to write some document that explains how such things are done.
- mSparks 10y agocant be any worse than openssl. 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?
- BillinghamJ 10y ago> cant be any worse than openssl. 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.
- mSparks 10y agowell. actually looks better from the start: 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.
- wbl 10y agoOpenSSL does not have half the fixes people think it does. Generally what gets fixed is the ciphersuites some people happen to use, and the rest remain broken. For example, the constant time ECDSA signing only works with some curves, not all. It still supports horrific hacks for random number generation, instead of using OS provided interfaces. NSS is not much better on this front, but does a far better job of parsing TLS records in a sane way.
- deleted 10y ago[deleted]
- byuu 10y agoThis thinking is why Heartbleed was such a disaster. Everyone left it to someone else, and the end result was OpenSSL being the only serious choice. Yet even the 'experts' got it wrong -- way wrong. 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.
- oconnor663 10y ago> 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. Wouldn't you say DJB (et al) did that themselves? https://tweetnacl.cr.yp.to/ https://tweetnacl.cr.yp.to/
- byuu 10y agoI haven't benchmarked TweetNaCl's performance yet, but I think that goes way too far into making the code completely unreadable. The 80%/10% number I gave is against the ref10 implementation. Compare theirs: https://tweetnacl.cr.yp.to/20140427/tweetnacl.c https://tweetnacl.cr.yp.to/20140427/tweetnacl.c To mine: https://gitlab.com/higan/higan/blob/master/nall/elliptic-curve/curve25519.hpp https://gitlab.com/higan/higan/blob/master/nall/elliptic-cur... https://gitlab.com/higan/higan/blob/master/nall/elliptic-curve/ed25519.hpp https://gitlab.com/higan/higan/blob/master/nall/elliptic-cur... https://gitlab.com/higan/higan/blob/master/nall/cipher/chacha20.hpp https://gitlab.com/higan/higan/blob/master/nall/cipher/chach... https://gitlab.com/higan/higan/blob/master/nall/mac/poly1305.hpp https://gitlab.com/higan/higan/blob/master/nall/mac/poly1305... https://gitlab.com/higan/higan/blob/master/nall/hash/sha256.hpp 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.)
- deleted 10y ago[deleted]
- akie 10y agoI still think it applies.
- keymone 10y agothis might give people false sense of security. implementing own crypto exposes you and those few souls that bought into your story. implementing bug-free "proven crypto" is near impossible task, but "proven crypto" part sells much better and so exposes many more un-expecting victims.
- throwawayReply 10y agoNobody gets fired for linking openssl.
- nine_k 10y ago...yet. Not sure about 10 years from now.
- user5994461 10y agoYour own implementation of an algorithm is also a cliche. Use proven and battle tested library. You won't do any better on your own.
- tptacek 10y agoWhoah, no. It's about building crypto code at all. 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.
- pornin 10y agoIt is a combination of "many eyes" and "good documentation". What is needed is some good text that describes the design choice, the rationale, and all the tricky details; and then people who read it and think about it. I'll write and publish such text within the next few months.
- xdej 10y agoYou could use some of your 233,693 reputation points as bounties on security.SE to attract people to read and think about bearssl.
- rdeboo 10y agoSo I guess it is going to take years. 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.
- baby 10y agoany RSS feed to be able to catch that?
- mpettitt 10y agoThis is a very important point. When it comes to implementing new software, especially in a critical field like crypto, it takes a long time for acceptance to build. 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.
- dchest 10y agoI was skeptical, but then saw: author Thomas Pornin Yeah, "should not implement your own crypto" doesn't apply to him.
- btown 10y agoFrom his CV http://www.bolet.org/~pornin/cv-en.html http://www.bolet.org/~pornin/cv-en.html : 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). Yeah, doesn't apply to him.
- mythz 10y agoDefinitely, most of my crypto searches ends up landing on one of his answers :)
- avhon1 10y agoAfter a little bit of looking around on the internet, I think I agree.
- hbbio 10y agoAnd you are Dmitry! We use your TweetNacl-js implementation for https://github.com/wallix/PEPS https://github.com/wallix/PEPS!
- stonemetal 10y agoMy understanding is it generally takes years. First it is reviewed by multiple security professionals who look for known attacks. Once it is generally thought to be ok it sees limited real world use. There it generally just takes trial and error time.
- Perceptes 10y ago> written in C Stopped reading there.
- bandrami 10y agoWhy? Crypto in a memory-managed language is not just a bad idea but a horrifically bad idea because you expose yourself to every single bug in the runtime's memory management.
- oconnor663 10y agoA lot of people are arguing that new projects like this should use Rust. Like https://github.com/ctz/rustls https://github.com/ctz/rustls.
- user5994461 10y agoOnly because they don't know Ada and they wanna reinvent the wheel again /s
- adrianN 10y agoI agree that Ada is a lot better than C, but the guarantees Ada provides are different from the guarantees Rust provides.
- pcwalton 10y agoAs soon as you call (the equivalent of) malloc/free in Ada you either need a GC or you're in undefined behavior land. In Rust, that is not true. Obviously, being able to call malloc without a GC is a nice to have for TLS on embedded systems.
- mbanzi 10y agoAre there mature versions of rust for the hundreds of microcontrollers that people are in production right now? Most of them have a decent GCC port and C works on all of them..
- crb002 10y agoNeeds some Galois SAW tests. Also using OpenSSL for testing wouldn't be a bad idea.
- eganist 10y agoEdit: http://www.bolet.org/~pornin/cv-en.html http://www.bolet.org/~pornin/cv-en.html Disregard me.
- drzaiusapelord 10y agoSays who? Maybe the cruft of the old ones means its impractical to fix. Maybe the leadership of the old ones means it can't be fixed due to incompetence or toxic politics. Sometimes rolling your own or forking is the smart move. There's a reason you use x.org and not xfree86 for example. 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.
- deleted 10y ago[deleted]
- eganist 10y agoDoesn't matter anymore -- the credibility of the person leading the project is thoroughly established, so I'm retracting my comment. 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."
- mythz 10y agoThe last thing the world needs is another immature SSL/TLS implementation however this makes it very interesting: > 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 http://security.stackexchange.com/users/655/thomas-pornin
- stompin 10y agoIs there any evidence that memcpy/memmove outperform malloc?
- bluejekyll 10y agoI think the implication is that without malloc you will remove a slew of potential bugs related to memory management, making the software more stable.
- stompin 10y agoand moves and copies won't have potential for other memory management bugs? You'll still have memory management overhead and now additional complexity.
- moduspwnens14 10y agoAt a high level, isn't this like implementing your own "malloc" and "free" that just pulls from your process's own memory pool instead of the OS? Or is there more to it than that?
- unwind 10y agoThis 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.
- pornin 10y agoHonestly, 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.
- pfalcon 10y ago> 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?)
- unwind 10y agoOkay, 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=9edaadd1ffc799655830e87f0d77b447e58d934d;hb=HEAD 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.
- zAy0LfpBZLC8mAC 10y agoI 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?
- deleted 10y ago[deleted]
- nwmcsween 10y agoPlease make a openssl compat api if possible, its incredibly hard porting n programs to $ssl.
- majewsky 10y agoI'm pretty sure that this library would lose many of its advantages (small footprint, no allocations) when you slap an OpenSSL facade on it.
- dimman 10y agoNo really he should not. A separate translation layer is free for anyone to write though. The OpenSSL design from an API perspective is basically as far from "user friendly" as possibly possible. Having a hard-to-use API means that it's hard to get things right. If things are hard to get right it leads to more bugs. You get where I'm going with this. 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).
- nwmcsween 10y agoI don't really know what you mean about a hard-to-use api as openssl compat would just wrap the bearssl api and not make any difference to consumers of bearssl.
- fdr 10y agoThe problem is that OpenSSL's API itself is quite complicated and probably not in an entirely necessary way. As but one concrete example, there's almost no particularly satisfying way to handle the "error queue" in a world with imperfect software. I also recently found how how insanely impractical it is in practice to perform one's own certificate validation (e.g. so I could interpret the CN field) if a TLS connection is abstracted even a tiny bit (e.g. in a database driver). Little doubt that someone would find it useful, but it is An Undertaking, to preserve something which is not that desirable.
- falcolas 10y agoAn obvious dig at wolfSSL - I'd be curious to see a comparison between the two. wolfSSL appears to be the more mature of the two (which makes sense, it's been in use for over a decade, and has a business dedicated to its development).
- ayrx 10y agoNot quite, Thomas's avatar in many places is that of a bear. He has named a few of his works after bears, in particular his password hashing function Makwa.
- falcolas 10y agoI'll admit, they're a local company that I have a fair bit of respect for, so I'm a bit protective about people attacking them. That said, BearSSL is just too close to be coincidence. 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.
- mythz 10y agoIt has nothing to do with WolfSSL, Thomas uses a Bear as his avatar, done. I've never heard of WolfSSL, but Thomas's name and avatar was instantly familiar as someone who's contributed a wealth of invaluable Crypto knowledge to the world.
- vukk 10y agoBut then you don't have the homophone bear/bare, with "bare" having some nice connotations when your context of the topic includes OpenSSL.
- gardarh 10y agoHuh, the first thing that came to my mind when I saw the name was this thing: https://matt.ucc.asn.au/dropbear/dropbear.html https://matt.ucc.asn.au/dropbear/dropbear.html . Apparently forest animals are popular in the SSL implementation writing crowd.
- deleted 10y ago[deleted]
- savara 10y agoThe page claims: "[...] insecure protocol versions and choices of algorithms are not supported, by design", 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.
- DasIch 10y agoThere is not supporting insecure protocols and then there is living in fantasy land away from everyone else. You can't drop all of these things and end up with something generally useful.
- sintalfoob 10y agoWhy not? TLS 1.3 is dropping those algorithms.
- tptacek 10y agoSee how much of the Internet you can talk to if you only support TLS 1.3.
- tedunangst 10y agoCloud flare isn't the internet?
- tomlogic 10y agoThis. I recently worked on updating an embedded TLS implementation from TLS 1.0 to TLS 1.2. I was told that it didn't need to implement TLS 1.0 or TLS 1.1, but once deployed we found a lot of non-HTTPS servers still using TLS 1.0. In particular, Microsoft's Hotmail/MSN SMTP servers and multiple RADIUS servers on WPA/WPA2 Enterprise networks. It now allows for client connections to TLS 1.0 servers, but will only serve TLS 1.2 itself.
- savara 10y agoSure, I agree -- but that's not what the page claims. It says "insecure protocol versions and choices of algorithms are not supported, by design" -- the protocols and modes that I listed are known to have various insecurities, and it still supports them. I agree that to be useful it's necessary to support old, less secure or even insecure modes, but this is at odds with the above stated goal. My point is about the imprecise description.
- stompin 10y agoGiven various clues such as: -"OS-less" -small memory footprint -going out of their way to include discussion of legal jurisdictions -the author and past activities -performance seems not a major concern 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.
- DasIch 10y agoThis just looks like someone who is aware of the complex legal history associated with cryptography and has considered embedded devices in the design of the library. Considering the recent events around IoT having good crypto libraries for that seems like it could be useful.
- bluejekyll 10y agoI love the idea of a zero allocation crypto library, but isn't the fact that this is also in C going eventually lead down a similar path as that of OpenSSL? I'm personally really excited for this: https://github.com/briansmith/ring 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.
- lambda 10y ago> 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#unsafe 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.
- frutiger 10y ago> to avoid various timing attacks that could be introduced by optimization 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.
- deleted 10y ago[deleted]
- tptacek 10y agoThis is true but not relevant to the discussion: whatever side channel problems you'd have in pure assembly, you're practically certain to have more of them if you implement crypto in a high-level language with an aggressive optimizer.
- federicoponzi 10y agoI'm wondering why this isn't on github
- pornin 10y agoI wanted a clear situation with regards to laws on cryptographic software distribution and export. With my own server, I can keep everything in Canada, which makes things simpler.
- euyyn 10y agoWhy not run Gitlab on that server?
- dchest 10y agoIt's hard to get by without all the fancy CVE features in GitLab, but software written in Ruby on Rails is banned in Canada, so they had to use good ol' reliable gitweb.
- mSparks 10y ago->Rails is banned in Canada... 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.
- new_hackers 10y agohaha, I did the same thing. Must be trolling, or sarcasm
- mtgx 10y agoWhy bother with TLS 1.0 and TLS 1.1 anymore? I imagine by the time this project is "stable" Google would have already deprecated those two in Chrome. And 3DES? https://sweet32.info/ https://sweet32.info/
- lisper 10y agoAnother OpenSSL alternative: https://tls.mbed.org https://tls.mbed.org
- ncw33 10y agoIf Thomas has enough time to finish it (bearing in mind the hundreds of hours it will take to bring it to production quality) - and if he has time to maintain it over the years - and if he is able to commit to years' worth of future maintenance - then this could become a very nice and usable implementation. 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.
- tptacek 10y agoLibraries like this are almost invariably a terrible idea: none of the more recent alternatives to OpenSSL I've seen have avoided resurrecting crypto bugs OpenSSL fixed years ago. But: Thomas Pornin! So, this is pretty neat. I hope lots of crypto people take a very hard look at it.
- jlgaddis 10y agoYeah, the general wisdom is, basically, "if you don't know what you're doing, leave the crypto to the experts". 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.)
- tptacek 10y agoYep!
- Tomte 10y agoBesides being a crypto professor, he managed to guess what CRIME was about, after it was announced that some bad OpenSSL advisory was imminent, but before it came out. Therefore the proposed bug squashing strategy of "just claim that there's a bug in XYZ and let him oracle what it is".
- shove 10y agofinally might be able to handle SSL requests on memory-constrained Arduino / ESP-8266 projects?! Yes please!
- diafygi 10y agoOh man, can't wait for the docs. TLS 1.2 on an ESP8266 would make it possible to use them with AWS IoT.
- bschwindHN 10y agoFrom what I understand, you can use them already with AWS IoT but I'm not sure if this solution is ideal or secure enough. Haven't used it personally but it's there: https://github.com/SuperHouse/esp-open-rtos/blob/master/examples/aws_iot/README.md https://github.com/SuperHouse/esp-open-rtos/blob/master/exam...
- client4 10y agoI wonder if the Bear reference is in relation to the other smaller SSL implementation in WolfSSL https://www.wolfssl.com/wolfSSL/Home.html https://www.wolfssl.com/wolfSSL/Home.html
- raesene2 10y agoThe bear is more a favourite animal of the author
- new_hackers 10y agoI first thought of PolarSSL, and thought there must be a connection there. (hmm apparently is now renamed to mbed TLS)
- israrkhan 10y agoSeems like it is trying to replace PolarSSL (now called mBed TLS). It even dervies the name from PolarSSL (Polar Bear). It is nice to have multiple options, however it can make the vulnerability management a nightmare. How many more SSL libraries do we need (OpenSSL, LibreSSL,S2N,GnuTLS), not to mention native SSL libraries (Secure Transport, SChannel)?
- byuu 10y agoWe need a crypto library that is easy to use in other applications that want security. This trainwreck of an API is the opposite of what we want: https://gnutls.org/reference/gnutls-gnutls.html 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.
- niftich 10y agoI, for one, am still waiting for the TLS library that's the spiritual equivalent of NaCl or libsodium; where the integration surface is narrowed to the essentials, and sensible and secure (internal) defaults predominate.
- NeutronBoy 10y ago> It even dervies the name from PolarSSL (Polar Bear I thought it was a play on 'bare' - e.g. only the basic features needed.
- SOLAR_FIELDS 10y agoProbably a triple entendre as the author is a frequent poster and high rep user on Security StackExchange where his profile pic has been a bear for years. The community even has a couple in jokes about it because one of the other high rep users also has a picture of a bear as his profile picture and they are affectionately referred to as "big bear" and "little bear".
- bluefox 10y agoI've been reading the code for T0 (a FORTH->C thingy), and I arrived at the conclusion that C# is a terrible language. The code itself is nice and clean if you assume it, though.
- amluto 10y agoThis could be an interesting code base to use in a kernel. It should just work.
- conductor 10y ago@pornin Thanks, we definitely need a secure and reputable TLS implementation with small footprint for IoT devices. [invalid issue removed]