111–120 of 206 posts
Please make a openssl compat api if possible, its incredibly hard porting n programs to $ssl.
No 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…
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.
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.
Earlier quoted context omitted.
A lot of people are arguing that new projects like this should use Rust. Like https://github.com/ctz/rustls .
Are 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..
let's start from this
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.
Earlier quoted context omitted.
Is there any evidence that memcpy/memmove outperform malloc?
Many real time systems and applications disallow heap usage, because they have formal verification requirements that can't be met with dynamic memory that may "run out" depending on run time state.
Earlier quoted context omitted.
I 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.
Why not run Gitlab on that server?
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.
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.