Hacker News Reader

Comment by pecg | Hacker News Reader

Writing a competent, simple replacement for GnuPG, yet PGP fully compatible, is one of the things I plan to do on the long road, thus I think neopg is a good idea, except the fact that they decided to use C++. I know that type safety is one of the considerations, but OOP always results in ambiguous unnecessarily complex code, and for me that defeats the purpose of simplicity. Nevertheless, the GnuPG codebase is a mess.

View on HN

They explicitly address the "Why C++?" question here: https://neopg.io/blog/cplusplus/

Choice quote:

There are many programming languages, and I believe in picking the right tool for the job. In the case of NeoPG, the priorities were:

- Support for strong cryptography.

- Compatibility with C application developers.

- Convert legacy code quickly.

- Tool support for QA.

Everything else is, at this point, a secondary concern. The Sequoia Project uses Rust, and I envy that. But the first thing they had to do was to wrap an existing C crypto library (they choose libnettle), because there is no high quality crypto library for Rust yet. That is their challenge.

My challenge will be to stay focussed on the parts of C++ that are actually helpful, and not get bogged down by the rest.

Is using a C library or crypto library that hard in Rust? That's first Ive heard of it being a problem. In high-assurance, it was standard to limit unsafety to the stuff behind interfaces of unsafe modules (incl FFI) in otherwise memory-safe, systems language. We didn't see this as a detriment esp if was C with its wide support.

> wrap an existing C crypto library

I know it's mostly semantics but calling C from C++ still requires some wrapping(extern "C", integrating build system, etc).

I've found with bindgen unless there's some crazy macro shenanigans going on it's actually quicker for me to integrate C libraries into Rust then wrangling CMake/Make/etc. The C FFI is very much a first-class citizen in Rust.

Even doubly so if we're talking about a cross-platform library.

NeoPG uses Botan, which is a crypto library written in C++. I recommend reading its source code and comparing it with, for example, libgcrypt.

Is most of the removed code functionality that is now in the crypto library used, Botan?

A blog post on the decision to use an external library might be good. Is there a reason to think that the library will be better maintained than code with similar functionality in GPG?

Great work by the way! Thank you!

C++ has a long and successful history of application development, regardless of project size (from 0 to >100 MLOC; from 1 guy sitting in his attic to thousands of engineers). Much like Java it isn't "hip". Instead people like to use "hip" languages with an underdeveloped ecosystem. Typical example: analysis tools, e.g. code analysers, performance and profiling tools.

Comments like "couldn't they have used $niche-lang.org instead of [C++/Java/...]" bore me, to be honest.

The fact that C++ is so widely used reflects the fact that it’s both old and acceptably designed. It does not even remotely indicate that it’s universally a good tool choice.

I think C++ is not a great choice for complex crypto software because it doesn’t have very good safety-by-construction properties and it has to deal with (extremely) untrusted and probably malicious input. Parsers written in C or C++ are historically one of the biggest attack vectors out there.

Okay, I'll bite. What language would be "a great choice" for complex cryptography applications, in your opinion?

At this point Rust is the clear winner, as it's providing higher safety for similar run-time speed.

Depends on the application. I would personally use Rust for embedded applications (since it’s low-overhead and ADTs are basically a requirement for safe parsers) and Haskell for non-embedded. But if neither of those float your boat, there are other safe-by-construction parser-friendly languages available, mostly from the ML family.

Ada with SPARK Ada variant and careful refcounting wouldve been my baseline given it's all safe by default before Rust came along. D also had potential. Now Rust with SPARK. Im keepimg SPARK in for semi-automated verification. Just rewriting Skein's C code in SPARK automatically found an error thanks to prover. If affording specialists, then something like F star used in miTLS verified stack, Isabelle/HOL, Jasmin language, and/or imperative ML. All core, trusted functionality done that way.

I choose languages with tight control on memory for crypto-related stuff since you want to prevent leaks. You'll follow with a covert-channel analysis to be sure. If not crypto and stopping code injection, then a memory-safe language with interface checks and input validation will cover most problems. Those have been around since one was deployed in first, business mainframe: Burroughs B5000.

What do you mean by imperative ML? Using a language from the ML family, but mostly its imperative features? Can you expand on that?

Yeah, I should have. There's been prior work porting linear types and other stuff (think Rust safety) like that to ML since that's an easy-to-analyze language academics like to work in. Tolmach et al actually made a converter for it to Ada one time. ML is also the language that most formal verification extracts to by default. CakeML is a verified compiler for ML. There's flow analysis and concurrent variants for it. So, ML by itself is a good choice for correct code that will get a lot of analysis. Imperative ML, imperative for the needed efficiency gains, combined with type systems like Rust's to ensure its safety with numbers mapped to say 64-bit can go a long way.

When I wrote it, though, I was mainly thinking of recent work that converts functional, verified specs into imperative specs that extracts to ML. I think that has a lot of potential for producing a pile of verified data structures with low cost similarly to the COGENT language that was used for ext2 filesystem. Got a link for Imperative/HOL-to-ML below.

http://www.ssrg.ece.vt.edu/~lammich/pub/itp15_sepref.pdf

I didn't expect anything interesting to come up as replies, but here we are - thanks for those insights.

Comments like these bore me, to be honest.

We all know C++ is a valid design decision. We all know more hip languages have underdeveloped ecosystems. Yet opinions on which language to choose are not devoid of value because it indicates interest, sparks conversations, and may initiate development of the tools needed to make them less 'underdeveloped'.

The only thing we don't need is people saying another person's opinion is boring.

EDIT: Also, they said they were disappointed they used C++. Maybe they wished they stuck with C?

What $LANG would you use if you had the time to dedicate to the project and were rewriting it starting today? Why would you choose $LANG?

(Not an attack -- a genuine question because I'm interested in your choice and reasoning.)

I’m not faulting you at all, but... different people know different tools, place premiums on different features, and of reach different conclusions as to what they wish to use. It's just an opinion, and comparing opinions is such a sterile exercise.

Whatever value you assign to $LANG, you will always encounter a denizen on HackerNews that disparages $LANG and would've used $LANG-prime, but by not actually moving first to start a project to achieve that aim with the tool of their choice, they kind-of ceded their right to criticise.

That’s my point of view, at least: don't criticise the artist's choice of tools. It's rude.

Using C++ by no means implies using OOP.

C++ has an excellent C FFI :-)

Reply on news.ycombinator.com