Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signify: Securing OpenBSD from Us to You

openbsd.org

Post reply on HN
Print view View original

61–70 of 88 posts

Re: Signify: Securing OpenBSD from Us to You

#61

Post by mortenlarsen »

nickpsecurity wrote: post #34
kragen wrote: 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…

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

Re: Signify: Securing OpenBSD from Us to You

#62

Post by nickpsecurity »

kragen wrote: post #58
nickpsecurity wrote: post #56

Earlier quoted context omitted.

@ kragen The FIPS 140-2 claim comes from the NSA's licensing of those patents and requirements: https://www.nsa.gov/business/programs/quick_facts.shtml Far as patents, there's a quite a variety of them with some filed within the current 20 year window. I repeat for a third time , do you have a resource with a list of patents relevant to ECC and showing that none of them apply to any current implementations (esp BSD l…

The references you've linked back up what I've said, not what you've said; not my problem if you don't understand them.

The references I linked cover 8 patents out of 130. For the fourth time, please link to evidence that they and the other 122 don't apply to anything we might build in ECC. And also that NSA and companies wasted millions on patent licenses for nothing.

Otherwise, it's obvious that you are spreading advice without the slightest idea of what's true here. Otherwise, you'll probably have a link to all those patents and analysis of how they don't apply that you can post within next few minutes. A link to analysis you and your side have already done rather than crap you're making up on the spot. You're faking it though, so you won't have anything to post.

Like everyone else in the ECC debate. Nothing but your word, which at one point thought patents didn't exist (neither the NSA nor anybody else has a patent on ECC). Given you're knee deep in this stuff and supposedly a security professional you must have been lying. There's no way you couldn't have known as a crypto/security geek that there were patents on ECC given all the debates. But you assured everyone here that nobody else has a patent on ECC. Such lies could've cost commercial groups that trusted you quite a lot.

I understand if you're more focused on dismissing the competition than proving 100+ patents don't apply to your claims. It's way less work that way. You'd have to dig them up, read them, evaluate them from a legal perspective, and write up reasons they don't apply. Complex, boring stuff compared to coding. I'll understand if you never take the effort to back your claims about 100+ patents and expect the rest of us to do the same.

Re: Signify: Securing OpenBSD from Us to You

#63

Post by ghshephard »

gwu78 wrote: post #60
ghshephard wrote: post #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 b…

"... 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.

Re: Signify: Securing OpenBSD from Us to You

#64

Post by ghshephard »

nickpsecurity wrote: post #53
kragen wrote: post #48

Earlier quoted context omitted.

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.

@ 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 wasn't a license for a certicom specific implementation?

Seriously, someone who is an expert in this field (if not the expert), has already made a pretty clear statement here on patent problems wth Ed25519: http://ed25519.cr.yp.to/software.html.

As of 2015.06.11 "The authors have not been notified of any claims of patent problems wth Ed25519."

Re: Signify: Securing OpenBSD from Us to You

#65

Post by kragen »

nickpsecurity wrote: post #62
kragen wrote: post #58

Earlier quoted context omitted.

The references you've linked back up what I've said, not what you've said; not my problem if you don't understand them.

The references I linked cover 8 patents out of 130. For the fourth time , please link to evidence that they and the other 122 don't apply to anything we might build in ECC. And also that NSA and companies wasted millions on patent licenses for nothing. Otherwise, it's obvious that you are spreading advice without the slightest idea of what's true here. Otherwise, you'll probably have a link to all those patents and a…

It is still true that neither the NSA nor anybody else has a patent on ECC, any more than anybody has a patent on computers at this point. I'm sure you can find 100+ patents with titles like "Parallel Digital Computer" with very little effort, though. That doesn't mean that anybody who wants to use a computer for something needs to worry they're infringing patents.

I am not a "security professional", nor have I ever been, nor have I ever claimed to be.

There is no "competition" involved here.

There is no "ECC debate".

You already linked to a Wikipedia article that explains the patent status of different ECC systems. It's not my problem if you don't understand it.

Re: Signify: Securing OpenBSD from Us to You

#66

Post by vbezhenar »

FullyFunctional wrote: post #10
atmosx wrote: post #2

@tedu writes: > There was a PGP usability study conducted a few years ago where a group of technical people were placed in a room with a computer and asked to set up PGP. Two hours later, they were never seen or heard from again. This argument doesn't hold ground. If "technical people" can not setup a new GnuPG key in 20 minutes, they are obviously not "technical" in this context. I'm 100% sure OpenBSD is absolutely…

I have the misfortune of having encrypted some files in the past with PGP. At the time, the default algorithm appeared to be IDEA which was removed since for patent reasons. Find the old sources and getting it to built is not trivial. These days I'm leaning towards bundling encrypted files along with the C code that encrypted it and that works better if the latter is small and self-contained.

That's a very interesting concept of a cross-platform self-unpacking archive. Unfortunately it requires the C compiler binary which is missing on the Windows platform out of the box. Perhaps some kind of tiny C compiler or interpreter windows binary might be bundled along for 99% compatibility.

Re: Signify: Securing OpenBSD from Us to You

#67

Post by mortenlarsen »

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

s/can/can't

Re: Signify: Securing OpenBSD from Us to You

#68

Post by elsjaako »

nickpsecurity wrote: post #18
pstrateman wrote: post #11

Earlier quoted context omitted.

Using gnupg unfortunately requires a fairly complete understanding of the specific Web of Trust model used. On top of that the interface is atrocious, go find someone with an image in their pubkey and try to display it from the command line. Good luck.

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.

Re: Signify: Securing OpenBSD from Us to You

#69

Post by rjcz »

nickpsecurity wrote: post #34
kragen wrote: 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…

> 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.

Re: Signify: Securing OpenBSD from Us to You

#70

Post by RexRollman »

sliverstorm wrote: post #12
pstrateman wrote: post #3

Earlier quoted context omitted.

He's written a tool that solves one problem using one set of algorithms and a very simple format in a few thousand lines of c. It almost certainly contains fewer bugs than gnupg.

Do one thing, and do it well

Praise be Unix.
Post reply on HN