9 ms·

Signify: Securing OpenBSD from Us to You

140 points by glass- 11y ago

atmosx 11y ago
@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.
- pstrateman 11y ago
  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.
  - sliverstorm 11y ago
    Do one thing, and do it well
    - RexRollman 11y ago
      Praise be Unix.
- brynet 11y ago
  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
  - jrcii 11y ago
    I'm surprised that there seems to be a consensus here that using the GPG command line tool is complicated when the HN community regularly discusses, for example, time complexity of algorithms.
    - pstrateman 11y ago
      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.
      - nickpsecurity 11y ago
        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 studied it in ages. I do use GPG every night with the right person on the other end, though. Still don't know anything else about it. Don't want to, either.
        elsjaako 11y ago
        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.
- FullyFunctional 11y ago
  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.
  - vbezhenar 11y ago
    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.
    - derefr 11y ago
      I know that the RAR format, for one, effectively embeds the compensating decompression program for whatever it did into the archive, in the form of some bytecode for a VM with an ABI that has been stable since RAR was created. So RAR has actually been a bunch of different algorithms over time, but unrar(1) doesn't need to care; it just runs the embedded program in its VM. (Most exciting fact: this means that older versions of the program can decompress archives created by newer versions, using algorithms that didn't exist at the time the older version shipped!) It would definitely be possible to do the equivalent for encryption. The main problem† being that while compression algorithms get outmoded, encryption algorithms break. This is true of all encryption, but it's especially scary when you can just scan a disk and signature-identify crackable files by the embedded algorithm. So, if you were going to do something like this, you'd probably want a higher-level abstraction than "self-describing encrypted file"; maybe something more like a "self-describing encrypted mutable volume." Mutable so that it would (hopefully) get an update() operation called on it at least every so often (even if just from a fsck-during-mount), letting it start a background process to change out an old-and-broken backing-store encryption algorithm for a new-and-trusted one (think of how bcrypt handles strength changes.) --- † There's also the performance problem: if you have a stable ABI, and it was frozen 20 years ago, how would you ever do something like elliptic-curve operations efficiently? Heck, doesn't using a frozen ABI mean you couldn't make use of a modern processor's native instructions for RSA ciphering et al? The answer to this, I think, is VM-runtime instruction-level pattern-recognition ala urbit's "jets". The new version of the encryption program would prepend a program for the stable ABI, that tells the old version how to (inefficiently) implement elliptic-curve decryption in terms of things it understands. However, running this program against a new version of the decryption VM would recognize the signature/pattern of "what elliptic-curve decryption instructions encoded in [this VM]'s ABI" looks like, and execute a native procedure with the same preconditions and postconditions as that instruction-sequence instead. Sort of like typehints for a JIT, but where the instruction-sequences themselves are the hints, since they have canonical forms.
- nickpsecurity 11y ago
  You made a good point: OpenBSD is way more complicated than GPG. I set up GPG with one command I got off the Internet. I also got a cheat sheet giving common commands I need for common scenarios. These people weren't just barely technical: they were unable to use Google as well. I'm dismissing the study as having little value. Need a new one with people who can follow steps they find on Google. If they fail, the author's point would stand. One more thing they forgot to mention: GPG is apparently so secure that Snowden leaks show that NSA hates running into it and even uses it internally. Biggest endorsement one can get. I'd replace the interface for sure, though, where users would never see it.
- kragen 11y ago
  The paper is full of jokes like this. It’s clear, though, that GPG is much larger than we would like our TCB to be, and that it does have serious usability problems, some of which are inherent to its trust model and therefore cannot be papered over by GPG frontends. (They don't, however, stop you from using it to authenticate upgrades, as Debian and Ubuntu do.)
elchief 11y ago
A recent reddit post where a (US) user ordered OpenBSD by mail: http://www.reddit.com/r/openbsd/comments/369vmw/looks_like_i_got_an_nsa_special_p/ http://www.reddit.com/r/openbsd/comments/369vmw/looks_like_i...
- vacri 11y ago
  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 11y ago
    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.
  - elchief 11y ago
    I think-hope he's kidding about the NSA part.
gull 11y ago
This is a good point: Revocation is probably a cure worse than the disease.
jedisct1 11y ago
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-resolvers https://github.com/jedisct1/dnscrypt-proxy#dnscrypt-enabled-... 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 11y ago
  That's definitely an improvement and pretty easy to use as well.
vacri 11y ago
It's bizarre that they consider https as an alternative to cryptographic signing, rather than an unrelated addition.
- nickpsecurity 11y ago
  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 11y ago
    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 11y ago
      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.
nickpsecurity 11y ago
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.
- sdevlin 11y ago
  Ed25519 and Curve25519 are not encumbered by any patents, see http://cr.yp.to/ecdh/patents.html http://cr.yp.to/ecdh/patents.html and http://ed25519.cr.yp.to/software.html http://ed25519.cr.yp.to/software.html. You should prefer state-of-the-art elliptic curve systems to RSA and finite field DH.
  - nickpsecurity 11y ago
    I appreciate the update on the situation for those curves.
    - deleted 11y ago
      [deleted]
    - kragen 11y ago
      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 11y ago
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 11y ago
  "... the complete absence of CA architecture, or web-of-trust..."
  - ghshephard 11y ago
    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 11y ago
      [deleted]
zmanian 11y ago
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!
458QxfC2z3 11y ago
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.
slasaus 11y ago
See this follow-up as well "Ted Unangst: signify shortcomings": https://news.ycombinator.com/item?id=9721737 https://news.ycombinator.com/item?id=9721737

140 points by glass- 11y ago

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

pstrateman 11y ago
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.
- sliverstorm 11y ago
  Do one thing, and do it well
  - RexRollman 11y ago
    Praise be Unix.
brynet 11y ago
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
- jrcii 11y ago
  I'm surprised that there seems to be a consensus here that using the GPG command line tool is complicated when the HN community regularly discusses, for example, time complexity of algorithms.
  - pstrateman 11y ago
    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.
    - nickpsecurity 11y ago
      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 studied it in ages. I do use GPG every night with the right person on the other end, though. Still don't know anything else about it. Don't want to, either.
      - elsjaako 11y ago
        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.
FullyFunctional 11y ago
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.
- vbezhenar 11y ago
  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.
  - derefr 11y ago
    I know that the RAR format, for one, effectively embeds the compensating decompression program for whatever it did into the archive, in the form of some bytecode for a VM with an ABI that has been stable since RAR was created. So RAR has actually been a bunch of different algorithms over time, but unrar(1) doesn't need to care; it just runs the embedded program in its VM. (Most exciting fact: this means that older versions of the program can decompress archives created by newer versions, using algorithms that didn't exist at the time the older version shipped!) It would definitely be possible to do the equivalent for encryption. The main problem† being that while compression algorithms get outmoded, encryption algorithms break. This is true of all encryption, but it's especially scary when you can just scan a disk and signature-identify crackable files by the embedded algorithm. So, if you were going to do something like this, you'd probably want a higher-level abstraction than "self-describing encrypted file"; maybe something more like a "self-describing encrypted mutable volume." Mutable so that it would (hopefully) get an update() operation called on it at least every so often (even if just from a fsck-during-mount), letting it start a background process to change out an old-and-broken backing-store encryption algorithm for a new-and-trusted one (think of how bcrypt handles strength changes.) --- † There's also the performance problem: if you have a stable ABI, and it was frozen 20 years ago, how would you ever do something like elliptic-curve operations efficiently? Heck, doesn't using a frozen ABI mean you couldn't make use of a modern processor's native instructions for RSA ciphering et al? The answer to this, I think, is VM-runtime instruction-level pattern-recognition ala urbit's "jets". The new version of the encryption program would prepend a program for the stable ABI, that tells the old version how to (inefficiently) implement elliptic-curve decryption in terms of things it understands. However, running this program against a new version of the decryption VM would recognize the signature/pattern of "what elliptic-curve decryption instructions encoded in [this VM]'s ABI" looks like, and execute a native procedure with the same preconditions and postconditions as that instruction-sequence instead. Sort of like typehints for a JIT, but where the instruction-sequences themselves are the hints, since they have canonical forms.
nickpsecurity 11y ago
You made a good point: OpenBSD is way more complicated than GPG. I set up GPG with one command I got off the Internet. I also got a cheat sheet giving common commands I need for common scenarios. These people weren't just barely technical: they were unable to use Google as well. I'm dismissing the study as having little value. Need a new one with people who can follow steps they find on Google. If they fail, the author's point would stand. One more thing they forgot to mention: GPG is apparently so secure that Snowden leaks show that NSA hates running into it and even uses it internally. Biggest endorsement one can get. I'd replace the interface for sure, though, where users would never see it.
kragen 11y ago
The paper is full of jokes like this. It’s clear, though, that GPG is much larger than we would like our TCB to be, and that it does have serious usability problems, some of which are inherent to its trust model and therefore cannot be papered over by GPG frontends. (They don't, however, stop you from using it to authenticate upgrades, as Debian and Ubuntu do.)

elchief 11y ago

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

vacri 11y ago
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 11y ago
  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.
- elchief 11y ago
  I think-hope he's kidding about the NSA part.

gull 11y ago

This is a good point: Revocation is probably a cure worse than the disease.

jedisct1 11y ago

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-resolvers https://github.com/jedisct1/dnscrypt-proxy#dnscrypt-enabled-... 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 11y ago
That's definitely an improvement and pretty easy to use as well.

vacri 11y ago

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

nickpsecurity 11y ago
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 11y ago
  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 11y ago
    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.

nickpsecurity 11y ago

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.

sdevlin 11y ago
Ed25519 and Curve25519 are not encumbered by any patents, see http://cr.yp.to/ecdh/patents.html http://cr.yp.to/ecdh/patents.html and http://ed25519.cr.yp.to/software.html http://ed25519.cr.yp.to/software.html. You should prefer state-of-the-art elliptic curve systems to RSA and finite field DH.
- nickpsecurity 11y ago
  I appreciate the update on the situation for those curves.
  - deleted 11y ago
    [deleted]
  - kragen 11y ago
    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 11y ago

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 11y ago
"... the complete absence of CA architecture, or web-of-trust..."
- ghshephard 11y ago
  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 11y ago
    [deleted]

zmanian 11y ago

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!

458QxfC2z3 11y ago

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.

slasaus 11y ago

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