Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BearSSL – Smaller SSL/TLS

bearssl.org

Post reply on HN
Print view View original

171–180 of 206 posts

Re: BearSSL – Smaller SSL/TLS

#171

Post by Florin_Andrei »

sp332 wrote: post #48
mbanzi wrote: post #26

Earlier quoted context omitted.

you should have read the rest before commenting. This is ideal for embedded targets and C is the best way to write a truly portable library for these small targets. Consider that a lot of embedded code is designed to avoid mallocs() altogether and that helps a lot.

Having a C binding doesn't mean you have to implement the bulk of the code in C.

Have you ever programmed a microcontroller?

(And yes, it would actually be nice to have reliable crypto on a micro-c.)

Re: BearSSL – Smaller SSL/TLS

#172

Post by makomk »

frutiger wrote: post #156
bradleyjg wrote: post #145

Earlier quoted context omitted.

Is there any way to write programs that bypass the processor's front end for most the processors in use? If not, it what sense is it true that "you can go further than assembler"?

You don't have much choice with commodity hardware - but you could perform crypto on hardware/chips where the behavior is completely specified. Note that this is not very practical, and impractical crypto is almost as good as no crypto.

This is often, though not always, the case with deeply embedded processors of the kind BearSSL seems to be designed for. There's generally some way to get predictable cycle-exact performance on them because it matters for some embedded applications.

Re: BearSSL – Smaller SSL/TLS

#173

Post by dbaupp »

sp332 wrote: post #48
mbanzi wrote: post #26

Earlier quoted context omitted.

you should have read the rest before commenting. This is ideal for embedded targets and C is the best way to write a truly portable library for these small targets. Consider that a lot of embedded code is designed to avoid mallocs() altogether and that helps a lot.

Having a C binding doesn't mean you have to implement the bulk of the code in C.

Some platforms only have (bug-ridden, poorly supported) C compilers available: i.e. there's no other language to write in, let alone bind to.

Re: BearSSL – Smaller SSL/TLS

#174

Post by jamhan »

isostatic wrote: post #131
andrewstuart2 wrote: post #127

Earlier quoted context omitted.

Well, presumably, if the author's last name is Porn in and your spam filter is pretty basic (or overzealous).

I wonder how it would cope with Scunthorpe

Or your name is "Olivia Gray". (True story, corporate mail filter blocked all that person's email)

Re: BearSSL – Smaller SSL/TLS

#175

Post by falcolas »

pcwalton wrote: post #134
falcolas wrote: post #35

Earlier quoted context omitted.

Rust can't target the same platforms C can. Rust is also (generally) more memory intensive than C for similar programs. This makes its use in embedded situations a non-starter (at least for now).

> Rust can't target the same platforms C can. I keep seeing this argument, but nobody actually names those platforms. Name one platform you need to run a TLS stack on that LLVM doesn't have support for. > Rust is also (generally) more memory intensive than C for similar programs [citation needed]

> [citation needed]

With all the usual disclaimers about the inaccuracy of benchmarks:

https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

As a side note, can you guarantee you are not allocating memory (calling malloc) with Rust? I know how to do it in C, but Rust has another layer of indirection.

> Name one platform you need to run a TLS stack on that LLVM doesn't have support for.

Have a look yourself:

    $ llc --version # CPU architectures supported by LLVM
vs. https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Archit...

Of particular interest to me are the AVR ATMega line of microprocessors, popular in Arduino boards and IoT devices everywhere. I'd personally love to see more IoT communication secured with TLS.

I do see a github repo for providing a LLVM backend for AVR processors, but it's not part of the LLVM project, nor is it even passing its own test suite at the point I'm writing this.

Re: BearSSL – Smaller SSL/TLS

#176

Post by revelation »

conradev wrote: post #124
rthille wrote: post #121

Earlier quoted context omitted.

You don't need TLS for that, you could simply use an HMAC and a shared secret, assuming you're not worried about people with physical access (and ability to get the secret) being able to create updates. Of course if you've got multiple instances of the device (not some hobby thing where they are all owned by you), then the secret for each device should be different so someone can't buy the device, determine the secre…

Wouldn't signing each release with a private key be the simplest solution here? (that can take many forms, but that general idea is how most software updates currently work)

RSA means big integer which means unhappy performance on devices that often don't even have floating point in hardware. I think elliptic curve could be faster?

Re: BearSSL – Smaller SSL/TLS

#177

Post by pcwalton »

falcolas wrote: post #175
pcwalton wrote: post #134

Earlier quoted context omitted.

> Rust can't target the same platforms C can. I keep seeing this argument, but nobody actually names those platforms. Name one platform you need to run a TLS stack on that LLVM doesn't have support for. > Rust is also (generally) more memory intensive than C for similar programs [citation needed]

> [citation needed] With all the usual disclaimers about the inaccuracy of benchmarks: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... As a side note, can you guarantee you are not allocating memory (calling malloc) with Rust? I know how to do it in C, but Rust has another layer of indirection. > Name one platform you need to run a TLS stack on that LLVM doesn't have support for. Have a look yourself:…

> https://benchmarksgame.alioth.debian.org/u64q/compare.php?la....

There are so many variables here that using the benchmarks game will not give you an accurate picture. You may well just be benchmarking jemalloc vs. glibc's allocator. jemalloc is tuned for speed of allocation in threaded contexts (with e.g. TLABs), not minimum memory usage. If you want, you can use the system allocator with Rust; for the benchmarks game we use jemalloc since it's faster.

> I know how to do it in C, but Rust has another layer of indirection.

How? Any function you call from some other library can call malloc under the hood.

> $ llc --version # CPU architectures supported by LLVM

I know there are architectures out there that LLVM doesn't support, but that doesn't mean anything unless people actually need those architectures. Not having PDP-11 support (one of the architectures on that list) doesn't make Rust a "non-starter".

> I do see a github repo for providing a LLVM backend for AVR processors, but it's not part of the LLVM project, nor is it even passing its own test suite at the point I'm writing this.

AVR support is coming along well.

AVR isn't exactly a first-class citizen among commonly used projects like OpenSSL. The reason why AVR support is immature is that few people need it. Not having that support isn't enough to make Rust a "non-starter", any more than it makes OpenSSL a "non-starter".

Re: BearSSL – Smaller SSL/TLS

#178

Post by revelation »

pilif wrote: post #76
bluejekyll wrote: post #57

Earlier quoted context omitted.

I think the implication is that without malloc you will remove a slew of potential bugs related to memory management, making the software more stable.

IMHO you're converting your heap buffer overflows into stack buffer overflows which are even easier to exploit.

Exploiting systems without dynamic memory is pretty meh.. that's some NSA level Stuxnet bespoke shit.

But no, judging from the code, you just give it one big fat I/O buffer that will usually come from .bss

Re: BearSSL – Smaller SSL/TLS

#179

Post by revelation »

wolf550e wrote: post #130
byuu wrote: post #60

Earlier quoted context omitted.

I 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 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/hi…

To me, C++ with operator overloading looks scary. I think a reviewer would choose to review the generated binary instead of the source code.

Well if operator overloading looks scary you haven't seen the assembly generated for C++ programs ;)

It's just full with con-/de-structor noise and don't even get me started with virtual function calls.

Re: BearSSL – Smaller SSL/TLS

#180

Post by reinar »

pcwalton wrote: post #170
reinar wrote: post #150

Earlier quoted context omitted.

> Name one platform you need to run a TLS stack on that LLVM doesn't have support for. MPC55xx there's no proper support even in GCC and we need to work with expensive WindRiver compiler for this target. personally I don't need TLS for my firmware, but someone might - as there's static without runtime alloc implementation available.

> MPC55xx Google suggests that this is essentially PowerPC. Is that not true?

I wish it was that easy.

our e200z6 core has PowerPC ISA, but there's a difference in hardware floating point support (here it's done by SPE) and we also need VLE. First one you could somehow get working, but with the latter - no way, its support was dropped by mainline gcc even after the patches were proposed, since it complicates the other parts of PowerPC port and is needed only by few people like me with deep embedded stuff (source: https://gcc.gnu.org/ml/gcc/2013-03/msg00172.html).

Post reply on HN