Live data from Hacker News

LibreSSL

libressl.org

181–190 of 262 posts

Re: LibreSSL

#181
post #126

With close to years of C under my belt, I believe it's a major error, today, to write a critical cryptographic library in C. OK, do the codecs in C if it's the only way to meet performance requirements. But the rest must be written in a language that's reasonably analyzable statically, and with adequate abstractions. Seriously, have you looked at the filthy mess of leaky abstractions that OpenSSL's BIO system is? How…

Like we always have to ask when somebody says what you have, "What's the alternative?" Whatever it is, it'll need to be very portable (well beyond just Linux, OS X and Windows), and it'll presumably need a free implementation on each of those platforms, and it'll need to be quite fast, and it'll need to support native compilation, and it'll need to support interoperability with existing code, and it'll need to be "sa…

Ada sounds like an excellent choice. Of course, it's No Fun By Design™, but it's very, very safe.

Re: LibreSSL

#182
post #161

I may have a stupid question but... While I really enjoy Theo's talks and writings, I wonder if the fact that the VCS is CVS ain't a security issue in itself? It's been really a long time I haven't used CVS but I remember that attempt to introduce backdoors in projects using Git as a (D)VCS have been caught (it was in the Linux kernel I think). IIRC some attempts were caught precisely because it's hard to fake SHA ha…

Git uses SHA-1 hashes, which have not been considered cryptographically secure since 2005. Git and CVS are both just tools. They each provide a server implementation, but it's uncommon to use either of these for write access in large projects. It's more common to wrap CVS or Git with a different frontend like HTTPS or SSH. My guess is that the OpenBSD guys use OpenSSH. This team is fanatical about security and proces…

"I am completely comfortable with them using whichever tools they want."

Forgive me for saying so and I doubt you intend it so, but statements like this is what gets us into trouble. At a certain point we need to trust the people that build the foundation for us, but only once we've done our due diligence. Most people, maybe not you since you seem to know more about the team, have not yet.

Re: LibreSSL

#183
I've been thinking recently about Heartbleed, and I was wondering if by writing C code to implement various network and cryptographic protocols, we're acting as human compilers for something that might be better represented in a more abstract format. I know there's some research on this already (the Austin Protocol Compiler), but does anyone here know of any other serious efforts to take the human out of the equation in terms of implementing protocols in C?

Re: LibreSSL

#185
post #183

I've been thinking recently about Heartbleed, and I was wondering if by writing C code to implement various network and cryptographic protocols, we're acting as human compilers for something that might be better represented in a more abstract format. I know there's some research on this already (the Austin Protocol Compiler), but does anyone here know of any other serious efforts to take the human out of the equation…

C is only used because for cryptography we really need to be close to the CPU and memory, going all assembler is an option actually. Anything higher than that and you have to have formal proofs for your compiler as well as your equations.

Re: LibreSSL

#186

https://twitter.com/matthew_d_green/status/45696043584599654...

Matthew Green ‏@matthew_d_green Apr 18: "@MiodVallat @cwlcks Well then I withdraw my earlier comments. What happens in BSD when the system RNG lacks entropy? Does it block?"

Re: LibreSSL

#187
post #30

OpenBSD folks, what is your obsession with CVS????

Well, we're all waiting for you to write a BSD licensed git/hg replacement that has decent performance on a VAX.

Re: LibreSSL

#188
post #185
post #183

I've been thinking recently about Heartbleed, and I was wondering if by writing C code to implement various network and cryptographic protocols, we're acting as human compilers for something that might be better represented in a more abstract format. I know there's some research on this already (the Austin Protocol Compiler), but does anyone here know of any other serious efforts to take the human out of the equation…

C is only used because for cryptography we really need to be close to the CPU and memory, going all assembler is an option actually. Anything higher than that and you have to have formal proofs for your compiler as well as your equations.

Don't listen to him, its just for performance, compatibility and portability. There's many other reasons why you might want to use another language, and some do.

Re: LibreSSL

#189
post #176
post #161

Earlier quoted context omitted.

Git uses SHA-1 hashes, which have not been considered cryptographically secure since 2005. Git and CVS are both just tools. They each provide a server implementation, but it's uncommon to use either of these for write access in large projects. It's more common to wrap CVS or Git with a different frontend like HTTPS or SSH. My guess is that the OpenBSD guys use OpenSSH. This team is fanatical about security and proces…

SHA-1 has been shown to not be collision-resistant. Correct me if you've heard otherwise, but I believe SHA-1 is still believed to be second-preimage resistant. In other words, with fewer than 2 * * 80 trials, an attacker can generate two files that have the same SHA-1 hash. (In the case of C source files, this probably means embedding a nonsense comment in the middle of each file, probably several hundred to several…

Conversely there are other signing techniques. GPG signed tags is an officially supported method.

Probably more importantly though, Git encourages everyone to have the full repository lying around. Even if you inserted a vulnerability in a master, there would still be thousands of copies of code which could be independently compared to find the exact changes which were made.

Re: LibreSSL

#190
post #128

Earlier quoted context omitted.

Portable OpenNTPD seems to have died: https://wiki.archlinux.org/index.php/OpenNTPD I'm sure LibreSSL won't have that problem but I thought it worthwhile pointing out that support for other OSes is not guaranteed.

>Portable OpenNTPD seems to have died: https://wiki.archlinux.org/index.php/OpenNTPD If you follow that through the series of links, you find that it is just an assumption based on one guy who didn't know the project existed thinking unchanged = unmaintained.

Are you sure? There hasn't been a release for 8 years.

I followed the links a while ago after hitting an intialization failure bug that leaves Linux boxes with the incorrect date. I found that neither Arch Linux or Redhat consider OpenNTPD to be supported on Linux.

Edit: a better link https://bugzilla.redhat.com/show_bug.cgi?id=430143

Post reply on HN