Signify: Securing OpenBSD from Us to You • Hacker News Board

Re: Signify: Securing OpenBSD from Us to You

#71

Post by nickpsecurity » Sat, Jun 13, 2015, 2:37 PM UTC

rjcz wrote: post #69

nickpsecurity wrote: post #34

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…

> Along with a warning that the key didn't have others' signatures on it, which ironically re-assured me more because it shouldn't. You have stated in other comments that you don't fully understand the web of trust concept - I'd go a little bit further and, based on the above, say that you haven't a slightest clue about it.

There's a good reason for that, actually. Besides, it doesn't matter how long ago I went to key-signing parties and such. The number of people I know using PGP I can count on one hand, maybe two. I have reliable channels to them to get keys. Web of trust is useless to me and despite my poor memory I can remember debating people about its many weaknesses even back when we did it a lot.

Modern tech has moved on to more interesting and reliable reputation systems. Web of trust's time has passed, for now.

Re: Signify: Securing OpenBSD from Us to You

#72

Post by nickpsecurity » Sat, Jun 13, 2015, 2:39 PM UTC

mortenlarsen wrote: post #61

nickpsecurity wrote: post #34

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…

The problem with copying and pasting from a website is not whether you think you know what the command does. It is that copying from a HTML page might contain stuff you can see. https://thejh.net/misc/website-terminal-copy-paste

Damn! That was a surprise! Alright, point taken. I'll... have to validate things on terminals a lot more thoroughly in the future. And type my own code by hand based on the documentation. Maybe just make my own cheat-sheets for the cut and paste. Text files.

Re: Signify: Securing OpenBSD from Us to You

#73

Post by nickpsecurity » Sat, Jun 13, 2015, 2:42 PM UTC

elsjaako wrote: post #68

nickpsecurity wrote: post #18

Earlier quoted context omitted.

You actually just need a reliable way to get information from them once plus a good cheat sheet (see above comment) on GPG. So, you both use cut and paste to (a) generate keys, (b) add keys, (c) send messages and (d) receive messages. Exchanging the key file is the only step that requires slight thought and there's a dozen ways to do that. I still don't use or fully understand the web of trust model as I haven't stud…

But then a friend tries to be more secure and sends something using --throw-keyids or --hidden-recipient. He tells me I should use --try-all-secrets, but adding that to enigmail doesn't work. I still don't know why. I'm trying to do this with some friends, and we keep on running into problems like that. Everything turns out to be easy to solve, but only if you know exactly how it works.

You'd have to be an idiot to read those command names and try them. Whereas "gen-key," "import," "export," "-e," and "-d" have obvious, low-risk usage. More so if you cross-reference against the docs.

Nice strawman, though.

Re: Signify: Securing OpenBSD from Us to You

#74

Post by nickpsecurity » Sat, Jun 13, 2015, 2:46 PM UTC

ghshephard wrote: post #64

nickpsecurity wrote: post #53

Earlier quoted context omitted.

@ ghshephard Your comment implies they're only paying for an implementation. To be sure, do you have a link to a resource analyzing the patents on ECC and showing they don't apply to anything they (or we) use for ECC? That it's a moot issue in its entirety or mostly except for known cases? Otherwise, I'm going to guess that you're guessing like everyone else.

I'm not sure why you are responding to me here, but don't put words in my mouth. Your question was, "If it's patent free, why are people paying for it as I linked to?" - there are other reasons to purchase a technology than just the patent. Let me spin it another way, and put the ball back in your court. Not that this proves anything, but has anyone (recently) purchased a license for ECC patented technology, that was…

People only get hit with patent suits for commercial use that I'm aware of. They wouldn't be as it's all free and they don't monetize it. A commercial product using it is where the risk is. I'm assessing that risk.

Anyway, thanks for the link as he covers a lot of key patents and some prior art to use.

Re: Signify: Securing OpenBSD from Us to You

#75

Post by [deleted] » Sat, Jun 13, 2015, 3:04 PM UTC

ghshephard wrote: post #63

gwu78 wrote: post #60

Earlier quoted context omitted.

"... the complete absence of CA architecture, or web-of-trust..."

That decision eliminates a lot (50%, 75%, 90%?) of the complexity that comes with GPG and most CA architectures. It also means the keys can be typed in by hand.

[deleted]

Re: Signify: Securing OpenBSD from Us to You

#76

Post by gwu78 » Sat, Jun 13, 2015, 3:13 PM UTC

ghshephard wrote: post #63

gwu78 wrote: post #60

Earlier quoted context omitted.

"... the complete absence of CA architecture, or web-of-trust..."

That decision eliminates a lot (50%, 75%, 90%?) of the complexity that comes with GPG and most CA architectures. It also means the keys can be typed in by hand.

Correct.

Re: Signify: Securing OpenBSD from Us to You

#77

Post by zmanian » Sat, Jun 13, 2015, 3:27 PM UTC

One exciting thing about software distribution with ed25519 signatures is that when Ripple finally releases their threshold signature library for their cryptocurrency we get the ability to create public keys that express software signing policies for free!

Re: Signify: Securing OpenBSD from Us to You

#78

Post by tptacek » Sat, Jun 13, 2015, 4:33 PM UTC

quesera wrote: post #45

nickpsecurity wrote: post #40

Earlier quoted context omitted.

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.

You do not need a patent license to use ECDH or ECDSA on a NIST P-curve, nor do you need one to negotiate keys with Curve25519 or to sign with Ed25519.

This covers more or less everything a normal developer would ever do with elliptic curves.

Is there some wacky curve nobody uses that is patent-encumbered, or for which the point multiplication formula is based on patented math code? Maybe. Is there some wacky protocol --- not ECDH, not ECDSA, not EdDSA --- that's similarly encumbered. Yes! For instance: you need a license from Certicom to safely deploy ECMQV. NSA likes ECMQV, and licensed it.

You are not going to use MQV.

The same thing is true of conventional multiplicative group DH and RSA: there are variants and wacky protocols that are patented. Nobody uses them, nobody cares. They're the same kind of patent minefield as putting a shopping cart on a web page is: somebody somewhere has some godawful paper on it maybe, but you can't avoid it and still have a career.

The specifics of this situation aren't very complicated, but they're just complicated enough for people to spread mistrust of curve software. You've gotten a pageful of that on this thread. That's sad, because curve software is much more secure than RSA/DH. Every new system that requires public key crypto should be using curves.

Re: Signify: Securing OpenBSD from Us to You

#79

Post by tptacek » Sat, Jun 13, 2015, 4:44 PM UTC

nickpsecurity wrote: post #38

tptacek wrote: post #36

Earlier quoted context omitted.

You write this as if the comment I responded to wasn't right there for everyone to read. You said: NSA has a patent on ECC, expects licenses for commercial use, and has some kind of conditions you must adhere to My presumption was that you were referring to patents assigned to NSA. NSA had patents relevant to number theoretic crypto. They're long-expired. Apparently, what you actually meant was: NSA has licensed a pa…

That's a semi-clarification. You brought up foundational patents and NSA patents in a dismissal form. You didn't acknowledge any patent risk on ECC, the gist of my comment, at all. Anyone reading your comment would think there was no patent risk much like the other commenters. Might have not been your intention. Far as open source, the BSD licenses are used in part to encourage proprietary adoption of superior techno…

You keep using the words "ECC patents" as if they meant something. If you used the term "computer patents", your comments would be semantically identical.

Key agreement based on the elliptic curve discrete log problem isn't patented.

Straightforward, efficient point multiplication for elliptic curves --- the foundation of the ECDLP --- is not patented.

The the DLP-based DSA algorithm, which was invented at NSA, is not patented. Every browser uses it.

The elliptic curve variant of DSA, ECDSA, is not patented.

Fast floating point math mod 2^255-19: not patented. First published by a rabidly anti-patent researcher.

Elliptic curve point compression --- sending just the x, not the y --- was patented. Most researchers believe the patent was invalid; lots of very popular software ignored it. The patent has since expired.

Edwards curves? Bernstein claims to have invented Edwards curve cryptography, after being in the room when Harold Edwards published them.

Using elliptic curves in random number generators as a key escrow system? Certicom does appear to have a valid patent on that. So maybe that will cramp your style a bit.

I could keep going, breaking down binary extension fields, 3-party DH, ratchets, specific multiplication ladders, but that would defeat my point, which is that the most important, most mainstream, most typical uses of ECC --- the only things anyone should be doing with them --- are all unencumbered. That you can generate a first-principles binary extension field curve without tripping over a patent hardly matters. But it's also true.

Please stop spreading FUD.

Re: Signify: Securing OpenBSD from Us to You

#80

Post by dang » Sat, Jun 13, 2015, 8:46 PM UTC

rjcz wrote: post #69

nickpsecurity wrote: post #34

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…

> Along with a warning that the key didn't have others' signatures on it, which ironically re-assured me more because it shouldn't. You have stated in other comments that you don't fully understand the web of trust concept - I'd go a little bit further and, based on the above, say that you haven't a slightest clue about it.

> you haven't a slightest clue

No personal swipes, please.