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

141–150 of 206 posts

Re: BearSSL – Smaller SSL/TLS

#141

Post by frutiger »

tptacek wrote: post #120
frutiger wrote: post #95

Earlier quoted context omitted.

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

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

Note I never disagreed with GGP's premise - I'm only pointing out that you can go further than assembler.

Re: BearSSL – Smaller SSL/TLS

#142

Post by sigjuice »

usefulcat wrote: post #119
pilif wrote: post #76

Earlier quoted context omitted.

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

Not using the heap != everything is allocated on the stack. In situations where you want to avoid dynamic allocation, memory for most things that would otherwise have been dynamically allocated ends up being statically allocated at compile time.

Absolutely none of this is immune to buffer overflows.

Re: BearSSL – Smaller SSL/TLS

#143

Post by Sir_Cmpwn »

bluejekyll wrote: post #56

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

The problem with OpenSSL is less about the language it's written in and more about the age of the project, discipline of the developers, quality of the codebase, and its prevalance - which leads to its vulnerabilities having a high impact. OpenSSL's code is a heap of trash and that's why it's vulnerable, not neccessarily because it's written in C.

Re: BearSSL – Smaller SSL/TLS

#144

Post by mSparks »

dchest wrote: post #118
euyyn wrote: post #111

Earlier quoted context omitted.

Why not run Gitlab on that server?

It'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.

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

Re: BearSSL – Smaller SSL/TLS

#145

Post by bradleyjg »

frutiger wrote: post #141
tptacek wrote: post #120

Earlier quoted context omitted.

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

Note I never disagreed with GGP's premise - I'm only pointing out that you can go further than assembler.

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"?

Re: BearSSL – Smaller SSL/TLS

#146

Post by adrianN »

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)

Verifying a signature is not the simplest thing to do on hardware that doesn't even support a normal OS.

Re: BearSSL – Smaller SSL/TLS

#147

Post by oconnor663 »

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]

Maybe falcolas means that in the same way that C++ is more memory intensive than C for similar programs, because both C++ and Rust encourage a lot of Vecs/Strings that implicitly allocate on the heap?

Re: BearSSL – Smaller SSL/TLS

#150

Post by reinar »

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]

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

Post reply on HN