4 ms·

> Crypto isn’t a core competency for the standard library authors and this it’s better to offload that responsibility. Ring is mostly C/Assembly. Good bye safe

> Crypto isn’t a core competency for the standard library authors and this it’s better to offload that responsibility. Ring is mostly C/Assembly. Good bye safety ! Offloading core security routines is such a bad design. > The other reason to prefer a smaller standard library is that it can often be difficult to strip away the unused bits from the resultant binary. It’s actually already handled quite well, and could also be behind feature flags. Really, a standard library with feature flags and editions would make rust ridiculously much more productive… such a waste.

GreedCtrl 3y ago
For crypto, isn't assembly used to help prevent timing attacks? I don't know if that can be done in pure Rust.
- rastignack 3y ago
  At least let’s get rid of c and put this in stdlib, shall we ?
nindalf 3y ago
> Ring is mostly C/Assembly Crypto needs to be written in Assembly to ensure that operations take a constant time, regardless of input. Writing it in a high level language like C or Rust opens you up to the compiler "optimising" routines and making them no longer constant time. But you already knew this. And you also knew that the security audit (https://github.com/rustls/rustls/blob/master/audit/TLS-01-report.pdf https://github.com/rustls/rustls/blob/master/audit/TLS-01-re...) of ring was favourable > No issues were found with regards to the cryptographic engineering of rustls or its underlying ring library. A recommendation is provided in TLS-01-001 to optionally supplement the already solid cryptographic library with another cryptographic provider (EverCrypt) with an added benefit of formally verified cryptographic primitives. Overall, it is very clear that the developers of rustls have an extensive knowledge on how to correctly implement the TLS stack whilst avoiding the common pitfalls that surround the TLS ecosystem. This knowledge has translated reliably into an implementation of exceptional quality. As a bonus, rustls is under active development with sponsorship from Google, AWS and fly.io, with the aim of making a high quality, memory-safe TLS stack - https://www.memorysafety.org/initiative/rustls/ https://www.memorysafety.org/initiative/rustls/ You said > a standard library with feature flags and editions would make rust ridiculously much more productive What's the difference between opting into a library with a feature flag and opting in with a line in Cargo.toml? Let's say you want to use the de-facto regex library. Would it really be ridiculously productive if you said you wanted the "regex" feature flag instead of the "regex" crate? I do agree that the standard library does need a versioning story so they can remove long deprecated functions. Where it gets complicated is if a new method is reintroduced using the same name in a later edition.
- rastignack 3y ago
  > What's the difference between opting into a library with a feature flag and opting in with a line in Cargo.toml? Let's say you want to use the de-facto regex library. Would it really be ridiculously productive if you said you wanted the "regex" feature flag instead of the "regex" crate? If you are all alone developing and can audit the crate properly, sure. However when there’s a team, whose favorite lib should we pick ? How many of them shall we audit ? What’s their license ? How’s code attribution managed ? Etc etc
  - nindalf 3y ago
    Rust had a small standard library and that’s ok (https://blog.nindalf.com/posts/rust-stdlib/ https://blog.nindalf.com/posts/rust-stdlib/) Your concerns are valid, but Rust has chosen a different set of trade offs. The link outlines the pros and cons.

GreedCtrl 3y ago

For crypto, isn't assembly used to help prevent timing attacks? I don't know if that can be done in pure Rust.

rastignack 3y ago
At least let’s get rid of c and put this in stdlib, shall we ?

nindalf 3y ago

> Ring is mostly C/Assembly Crypto needs to be written in Assembly to ensure that operations take a constant time, regardless of input. Writing it in a high level language like C or Rust opens you up to the compiler "optimising" routines and making them no longer constant time. But you already knew this. And you also knew that the security audit (https://github.com/rustls/rustls/blob/master/audit/TLS-01-report.pdf https://github.com/rustls/rustls/blob/master/audit/TLS-01-re...) of ring was favourable > No issues were found with regards to the cryptographic engineering of rustls or its underlying ring library. A recommendation is provided in TLS-01-001 to optionally supplement the already solid cryptographic library with another cryptographic provider (EverCrypt) with an added benefit of formally verified cryptographic primitives. Overall, it is very clear that the developers of rustls have an extensive knowledge on how to correctly implement the TLS stack whilst avoiding the common pitfalls that surround the TLS ecosystem. This knowledge has translated reliably into an implementation of exceptional quality. As a bonus, rustls is under active development with sponsorship from Google, AWS and fly.io, with the aim of making a high quality, memory-safe TLS stack - https://www.memorysafety.org/initiative/rustls/ https://www.memorysafety.org/initiative/rustls/ You said > a standard library with feature flags and editions would make rust ridiculously much more productive What's the difference between opting into a library with a feature flag and opting in with a line in Cargo.toml? Let's say you want to use the de-facto regex library. Would it really be ridiculously productive if you said you wanted the "regex" feature flag instead of the "regex" crate? I do agree that the standard library does need a versioning story so they can remove long deprecated functions. Where it gets complicated is if a new method is reintroduced using the same name in a later edition.

rastignack 3y ago
> What's the difference between opting into a library with a feature flag and opting in with a line in Cargo.toml? Let's say you want to use the de-facto regex library. Would it really be ridiculously productive if you said you wanted the "regex" feature flag instead of the "regex" crate? If you are all alone developing and can audit the crate properly, sure. However when there’s a team, whose favorite lib should we pick ? How many of them shall we audit ? What’s their license ? How’s code attribution managed ? Etc etc
- nindalf 3y ago
  Rust had a small standard library and that’s ok (https://blog.nindalf.com/posts/rust-stdlib/ https://blog.nindalf.com/posts/rust-stdlib/) Your concerns are valid, but Rust has chosen a different set of trade offs. The link outlines the pros and cons.