
Signify: Securing OpenBSD from Us to You - glass-
http://www.openbsd.org/papers/bsdcan-signify.html
======
ghshephard
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
< 3 minutes for someone who already knows what a hash is.

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.

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

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

~~~
gwu78
Correct.

------
jedisct1
Another tool that generates compatible signatures:
[https://jedisct1.github.io/minisign/](https://jedisct1.github.io/minisign/)

The main addition is a "trusted comment" line, that can be used to verify
metadata, instead of just the content, for example to verify a timestamp and
prevent unwanted downgrades. This is not an issue with packages, but it can be
an issue with files that don't contain any version/timestamp.

And since keys are very short, they can also directly be given on the command-
line, making the verification very simple from a user perspective. For example
the list of public resolvers compatible with DNSCrypt can be verified with a
oneliner: [https://github.com/jedisct1/dnscrypt-proxy#dnscrypt-
enabled-...](https://github.com/jedisct1/dnscrypt-proxy#dnscrypt-enabled-
resolvers)

OpenWRT is now also leveraging Ed25519 signatures to sign their packages,
using a slightly modified version of signify. The result is way smaller than
GPG, and a better fit for embedded systems. Unfortunately, they sign
`sha512(message)` instead of the message itself, making the signature
incompatible with signify.

But even though they only do one thing, these tools are overall way easier to
use than GPG, way smaller, and having short keys is really great.

~~~
nickpsecurity
That's definitely an improvement and pretty easy to use as well.

------
elchief
A recent reddit post where a (US) user ordered OpenBSD by mail:
[http://www.reddit.com/r/openbsd/comments/369vmw/looks_like_i...](http://www.reddit.com/r/openbsd/comments/369vmw/looks_like_i_got_an_nsa_special_p/)

~~~
vacri
Given the NSA's reputation for doing things on the sly, isn't this a little
clumsy to attribute to them? As one of the commentators says, it was more
likely to be a border agent on the lookout for new music.

At one place I worked, we had USB security dongles for license management. We
started sending them out in envelopes, and found that few reached their
destination intact - the envelope would arrive, with a hole in the corner.
Someone was raiding the envelopes for USB sticks, for whatever reason.

~~~
kylebgorman
Could it be that they were damaged by the postal equipment? Envelopes with
keys often undergo this fate too, unless you pad the key with something of
similar thickness.

------
atmosx
@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 NOT fit for people who find GnuPG
confusing enough to avoid usage.

> Or as Prof. Green put it, "Can someone who built GnuPG 2.1.1 on
> Debian/Ubuntu give me a hint on which libgpg-error you used?" If he doesn't
> which libgpg-error to use, I doubt I'm going to pick the right one.

I can, here:

    
    
        $ pkg info|grep libgpg-error
        libgpg-error-1.19_1            Common error values for all GnuPG components
    

Given that this is @tedu, I'm sure I missed the point/joke.

The only real argument here is that it's at least 10 times easier to write
code than to read another mans code. So I give him that... Which one is more
secure, GPG or signify remains to be seen.

~~~
brynet
GnuPG is complicated, the gpg(1) man page is quite extensive compared to
signify.

I imagine very few people have set up PGP without the help of a search engine.

    
    
        $ man gpg | pr | grep Page | awk '{print $6}' | tail -1
        58
        $ man signify | pr | grep Page | awk '{print $6}' | tail -1
        2

~~~
nickpsecurity
I got back on GnuPG recently because an associate wouldn't communicate without
it. We came up with a trustworthy way to exchange keys. After that, I just cut
and pasted crap from this:

[http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/](http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/)

Been working fine so far. I'm sure there's all kinds of complicated ways to
use it but it just takes a few commands to do most of the work. I only use two
these days: one for sending and one for receiving. I scripted the more
complicated one (send) where I type an alias and a text file with it doing the
rest. The decrypt command, -d (file), is easy to remember. Pretty simple
compared to trying to learn OpenBSD.

Not to say they're wrong for making something easier or the interface couldn't
be way better. Just that me using this thing with almost no thought argues
against all this difficulty people are bringing up.

~~~
kragen
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?

~~~
nickpsecurity
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 other party decrypted. Along with
a warning that the key didn't have others' signatures on it, which ironically
re-assured me more because it shouldn't.

So, a visual inspection of the commands and their results in a sandboxed
machine was about all one needed to know that they worked. My experience with
similar tools helps there. More concerned people can thoroughly cross-
reference them with the documentation, source code, program's author, and so
on. Whatever level of assurance they like. The basic level, though, was
incredibly simple.

I'd take using GPG over learning Emacs or OpenBSD any day. In level of
difficulty, that is.

~~~
mortenlarsen
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](https://thejh.net/misc/website-terminal-copy-paste)

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

------
gull
This is a good point: _Revocation is probably a cure worse than the disease._

------
slasaus
See this follow-up as well "Ted Unangst: signify shortcomings":
[https://news.ycombinator.com/item?id=9721737](https://news.ycombinator.com/item?id=9721737)

------
vacri
It's bizarre that they consider https as an alternative to cryptographic
signing, rather than an unrelated addition.

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

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

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

------
458QxfC2z3
Linux port of signify:

[http://sourceforge.net/projects/slackdepot/files/signify/](http://sourceforge.net/projects/slackdepot/files/signify/)

Files signified on OpenBSD will verify on Linux and vice versa.

------
zmanian
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!

------
nickpsecurity
Quick comment regarding key sizes. NSA has a patent on ECC, expects licenses
for commercial use, and has some kind of conditions you must adhere to if
applying for a license. I'll let your imagination wonder on that last part as
mine does. The choice is easy for me between asymmetric crypto that's patent-
free and a kind the NSA controls. This might not apply to your personal use
but it can to any company using such a tool.

Given the leaked BULLRUN slide, I'd rather not be in a position of NSA showing
up with plans for my product along with a legal claim on it. RSA or DH it is,
then! Or clever symmetric schemes that avoid that stuff entirely. I do that,
too. I haven't missed not using ECC as I rarely need to transmit asymmetric
keys.

EDIT: The few legitimate responses to this showed NSA patents are expired,
Certicom's 130+ still require license from new owner Blackberry, and
Bernstein's curves _might_ be exempt. I appreciate those updates. Status quo:
forms of ECC are covered by patents and you need to consult an attorney if
doing it commercially.

~~~
quesera
> NSA has a patent on ECC ...

Wow, I was not aware that it was even _possible_ for government agencies to
hold patents.

Is there any reasonable justification for that?

~~~
kragen
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](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.

~~~
quesera
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-...](http://foreignpolicy.com/2014/07/30/the-nsas-patents-in-one-
searchable-database/)

Also, from
[https://www.nsa.gov/research/tnw/tnw193/articles/pdfs/TNW193...](https://www.nsa.gov/research/tnw/tnw193/articles/pdfs/TNW193_article4.pdf)
(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. Following extensive review,
> NSA may seek patent protection for such technologies as a way to protect and
> build on the US government’s (USG) investment in research and development.

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

