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.
Signify: Securing OpenBSD from Us to You
41–50 of 88 posts
Re: Signify: Securing OpenBSD from Us to You
#42Re: Signify: Securing OpenBSD from Us to You
#43Earlier 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…
Re: Signify: Securing OpenBSD from Us to You
#44Earlier 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/
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
#45Earlier 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.
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
#46Earlier 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…
Re: Signify: Securing OpenBSD from Us to You
#47Earlier 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.
Re: Signify: Securing OpenBSD from Us to You
#48Earlier 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.
Re: Signify: Securing OpenBSD from Us to You
#49Teaching 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
#50Earlier 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 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?