Live data from Hacker News

Signify: Securing OpenBSD from Us to You

openbsd.org

41–50 of 88 posts

Re: Signify: Securing OpenBSD from Us to You

#41

Earlier quoted context omitted.

My reading was they did the exact opposite: considered https to be a failure of end-to-end security they wanted. It was various users that apparently wanted HTTPS. I could see how they got to that: I access the site with HTTP; an intercept might happen; HTTPS protects HTTP; let's protect it with HTTPS! Fortunately, the experts knew better and avoided that nonsense.

If end-to-end sec (e.g., crypto signatures) are used, like say with Debian packages which uses GPG, packages and metadata can be released over http without a problem.

Exactly. One of many reasons the developers went with an end-to-end solution instead of HTTPS. It makes the transport mechanism moot except for the initial key exchange.

Re: Signify: Securing OpenBSD from Us to You

#43
post #27

Earlier quoted context omitted.

Are you really confident that cutting and pasting crap from a random web page (particularly one without TLS, so the guy sitting across from you at Starbucks can MITM it) provides you with sufficient understanding to notice when you are accidentally doing something insecure?

I cross-referenced it against the documentation. Let's assume someone won't, though. The commands' appearance make their intent pretty obvious. Further, using them produces output that confirms what the cheat sheet says. For instance, adding a public key said something along the lines of "public key added." Decrypting the incoming message showed its plaintext. Encrypting outgoing plaintext turned it into ciphertext o…

Agree with regard to Emacs, but OpenBSD has some of the best technical documentation I've ever come across. For example, their networking FAQ[0] or (especially) the PF guide[1].

[0] http://www.openbsd.org/faq/faq6.html

[1] http://www.openbsd.org/faq/pf/

Re: Signify: Securing OpenBSD from Us to You

#44

Earlier quoted context omitted.

I cross-referenced it against the documentation. Let's assume someone won't, though. The commands' appearance make their intent pretty obvious. Further, using them produces output that confirms what the cheat sheet says. For instance, adding a public key said something along the lines of "public key added." Decrypting the incoming message showed its plaintext. Encrypting outgoing plaintext turned it into ciphertext o…

Agree with regard to Emacs, but OpenBSD has some of the best technical documentation I've ever come across. For example, their networking FAQ[0] or (especially) the PF guide[1]. [0] http://www.openbsd.org/faq/faq6.html [1] http://www.openbsd.org/faq/pf/

Their documentation is great. I won't disagree in the slightest. I also praised them in other places for working as hard on docs as software itself. Docs are lacking in most places. The only point of these comments is that people are way overhyping the difficulty of basic GPG use given I installed it easily using Google and used it by cut n pasting a cheat sheet. Others have too. That's all I'm trying to do here while using things like the overall OpenBSD experience (or Emacs) as points of comparison to support that.

I'd have to use my brain with either OpenBSD stuff or Emacs. Of course, I cheated there too: Absolute OpenBSD. I know I could've used their great docs for everything but the reviews of the book were too good. I had to attempt using it to shortcut the learning process. Lol.

Re: Signify: Securing OpenBSD from Us to You

#45
post #37

Earlier quoted context omitted.

That's not what you said. You said NSA had patents, demanded licenses for their commercial use, and then more or less implied that the condition they imposed on the use of those curves was to backdoor or subvert software that use them. Obviously, no.

I've updated it for clarification. The NSA did have patents, though. After those expired, they licensed Certicom's and their web site even mentions that this only applies to products conforming to their expectations. As in, they control those to quite a degree. The alternative was paying Certicom a licensing fee. It's still on their web site.

See https://www.nsa.gov/business/programs/quick_facts.shtml for the ECC patent license agreement.

It appears to be free, but your use needs to pass some fairly specific restrictions. Not sure if the PLA is available at any cost if your use does not pass.

Re: Signify: Securing OpenBSD from Us to You

#46
post #30
post #23

Earlier quoted context omitted.

Neither the NSA nor anybody else has a patent on ECC. (And no, there is no reasonable justification for government agencies to hold patents, except to make them free to the public.) There are some patents on particular ECC techniques, as explained in http://cr.yp.to/ecdh/patents.html , but they do not cover the currently most popular ECC systems, and in any case they are mostly expired.

That's what I would have thought, but then I DuckDuckGo'ed it (awkward!)... http://foreignpolicy.com/2014/07/30/the-nsas-patents-in-one-... Also, from https://www.nsa.gov/research/tnw/tnw193/articles/pdfs/TNW193... (PDF): > You may be surprised to hear that NSA seeks patents. However, many of the technologies developed by NSA not only satisfy mission requirements, but also have great potential for commercial use. Fol…

I don't see anything in there that contradicts what I said.

Re: Signify: Securing OpenBSD from Us to You

#47
post #37

Earlier quoted context omitted.

That's not what you said. You said NSA had patents, demanded licenses for their commercial use, and then more or less implied that the condition they imposed on the use of those curves was to backdoor or subvert software that use them. Obviously, no.

I've updated it for clarification. The NSA did have patents, though. After those expired, they licensed Certicom's and their web site even mentions that this only applies to products conforming to their expectations. As in, they control those to quite a degree. The alternative was paying Certicom a licensing fee. It's still on their web site.

[deleted]

Re: Signify: Securing OpenBSD from Us to You

#48
post #19

Earlier quoted context omitted.

Ed25519 and Curve25519 are not encumbered by any patents, see http://cr.yp.to/ecdh/patents.html and http://ed25519.cr.yp.to/software.html . You should prefer state-of-the-art elliptic curve systems to RSA and finite field DH.

I appreciate the update on the situation for those curves.

It's not just those curves. Virtually all elliptic-curve cryptography is patent-free, as you would expect for a family of cryptosystems studied since 1986 based on centuries-old math. There are a few current patents, but they cover techniques almost nobody uses.

Re: Signify: Securing OpenBSD from Us to You

#49
Signify is the first OpenBSD code that I've ever read from start to finish - (minus the external libraries like the Ed25519 package). Watching the initial checkins, followed by the amazing improvement in the command line options within a a few weeks of checking by external contributors - the final product is much, much better than the first checkin. What I really appreciate, is that they managed to strike a balance between keeping the tool 100% lean, and adding tiny bits of syntactic sugar (such as the Untrusted Comment field, and, the ability to simultaneously verify the SHA256 hash and signature of a list of files.)

Teaching people how to use the tool, from the point of generating keys, to generating signature manifests for a packages, to signing, and verifying takes And, the complete absence of CA architecture, or web-of-trust - and an focus on sharing their (really short) public keys in a visible and widely distributed manner just makes the system so much simpler to understand.

For example - this literally is all you have to do on OS X to have a complete end-end signing/manifest/verification system:

Generate your keypair:

   signify -G -p pub -s sec
Your public key is tiny, and can be shared anywhere/everywhere:

  RWRGNg6NU+JAt9ju3ItQfOMmDhXmEkHp28mej8ickx4lOJjE2Tg2DxEO
Created your manifest (On OpenBSD you just go "sha256 file* ")

   shasum -a 256 file* | awk '{print "SHA256 ("$2") = "$1}'> manif
Sign your manifest, and embed the signature in the resulting sig file:

   signify -S -e -s sec -m manif -x manif.sig
And now, anybody who has your public key, can verify that manifest:

   signify -C  -p pub -x manif.sig
That's it, that's the entire system from beginning to end.

Re: Signify: Securing OpenBSD from Us to You

#50
post #48

Earlier quoted context omitted.

I appreciate the update on the situation for those curves.

It's not just those curves. Virtually all elliptic-curve cryptography is patent-free, as you would expect for a family of cryptosystems studied since 1986 based on centuries-old math. There are a few current patents, but they cover techniques almost nobody uses.

If it's patent free, why are people paying for it as I linked to? NSA paid for it and are specific that it applies to FIPS 140-2 solutions. Companies were paying Certicom for it. As far as a few years ago, an article gripes about how much Blackberry charges for it. Just weird that it doesn't apply to anything yet companies and governments were all paying for it.

If something has changed, I'd like the definitive answer to come from legal experts (esp aforementioned companies' lawyers) who say the 100+ patents no longer apply to anything we use and they all stopped paying for ECC. Haven't seen it. I'll continue to warn people until (a) I see that contrary reports acknowledge the existence of 100+ patents that companies are actually paying for rather than falsely claim no patents exist and (b) show why all of them never applied or no longer apply to existing ECC schemes. Got a link to that?

Post reply on HN