BearSSL – Smaller SSL/TLS • Hacker News Board

Re: BearSSL – Smaller SSL/TLS

#101

Post by tdb7893 » Thu, Nov 03, 2016, 4:37 PM UTC

darksaints wrote: post #98

mythz wrote: post #14

The 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,…

What sorts of applications are written for OS-less systems that require a TLS library? 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.

probably could be useful in some small "internet of things" device

Re: BearSSL – Smaller SSL/TLS

#102

Post by novaleaf » Thu, Nov 03, 2016, 4:38 PM UTC

darksaints wrote: post #98

mythz wrote: post #14

The 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,…

What sorts of applications are written for OS-less systems that require a TLS library? 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.

i would imagine as some sort of secure-boot or trusted hardware process.

Re: BearSSL – Smaller SSL/TLS

#103

Post by client4 » Thu, Nov 03, 2016, 4:41 PM UTC

I wonder if the Bear reference is in relation to the other smaller SSL implementation in WolfSSL https://www.wolfssl.com/wolfSSL/Home.html

Re: BearSSL – Smaller SSL/TLS

#104

Post by jws » Thu, Nov 03, 2016, 4:59 PM UTC

darksaints wrote: post #98

mythz wrote: post #14

The 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,…

What sorts of applications are written for OS-less systems that require a TLS library? 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.

Reasons for SSL:

• 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)

Re: BearSSL – Smaller SSL/TLS

#105

Post by throwaway2016a » Thu, Nov 03, 2016, 5:00 PM UTC

tdb7893 wrote: post #101

darksaints wrote: post #98

Earlier quoted context omitted.

What sorts of applications are written for OS-less systems that require a TLS library? 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.

probably could be useful in some small "internet of things" device

This. Internet of Things especially can benefit from adding TLS.

Re: BearSSL – Smaller SSL/TLS

#106

Post by raesene2 » Thu, Nov 03, 2016, 5:03 PM UTC

client4 wrote: post #103

I wonder if the Bear reference is in relation to the other smaller SSL implementation in WolfSSL https://www.wolfssl.com/wolfSSL/Home.html

The bear is more a favourite animal of the author

Re: BearSSL – Smaller SSL/TLS

#107

Post by Tomte » Thu, Nov 03, 2016, 5:15 PM UTC

jlgaddis wrote: post #90

tptacek wrote: post #89

Libraries 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.

Yeah, 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.)

Besides 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".

Re: BearSSL – Smaller SSL/TLS

#108

Post by StavrosK » Thu, Nov 03, 2016, 5:28 PM UTC

skykooler wrote: post #79

mythz wrote: post #14

The 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,…

And it seems the firewall here has made a clbuttic mistake, as that page is blocked due to the url containing "porn".

So you're pretty much out of luck if you want to visit a page that contains some analysis?

Re: BearSSL – Smaller SSL/TLS

#109

Post by [deleted] » Thu, Nov 03, 2016, 5:30 PM UTC

frutiger wrote: post #95

lambda wrote: post #85

Earlier quoted context omitted.

> 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 leav…

> 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]

Re: BearSSL – Smaller SSL/TLS

#110

Post by stavros » Thu, Nov 03, 2016, 5:30 PM UTC

darksaints wrote: post #98

mythz wrote: post #14

The 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,…

What sorts of applications are written for OS-less systems that require a TLS library? 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.

I very badly need a TLS library in my embedded firmware so I can accept new firmware updates over HTTP.