[HN Gopher] Sequoia 1.3
       ___________________________________________________________________
        
       Sequoia 1.3
        
       Author : teythoon
       Score  : 148 points
       Date   : 2021-06-08 10:11 UTC (12 hours ago)
        
 (HTM) web link (sequoia-pgp.org)
 (TXT) w3m dump (sequoia-pgp.org)
        
       | signal11 wrote:
       | Good to see this project make progress -- well done to the
       | development team. Whatever you think about pgp, it's not going
       | away anytime soon, and a new implementation is an opportunity to
       | brush away some cobwebs and even improve the ecosystem[1].
       | 
       | [1] https://sequoia-pgp.org/holistic-approach/
        
       | cassepipe wrote:
       | Anyone has a good tutorial on how to use sq, their command line
       | utility?
        
         | tlamponi wrote:
         | It's not a tutorial in the classic sense, but as the CLI is
         | rather simple, and as there are examples, I'd point you at the
         | official docs (man page like):
         | 
         | https://docs.sequoia-pgp.org/sq/index.html
         | 
         | The sub commands feel like they are pretty much self-
         | explanatory to me, e.g., encrypt, decrypt, verify are pretty
         | clear in what they will do, and the options for those sub-
         | commands seem not to cryptic either to me, but that's naturally
         | a bit opinionated.
         | 
         | Besides that the initial release news article of the sq tool
         | has some quick demo: https://sequoia-
         | pgp.org/blog/2021/01/26/202101-sq-release/
         | 
         | What would be your use cases for sq?
        
           | _hyn3 wrote:
           | "seem not too cryptic"
           | 
           | nice.
        
       | dralley wrote:
       | I know they plan to relicense from GPL to MPL eventually, but I
       | wish they would do it sooner rather than later.
       | 
       | I don't even mind the GPL, in fact most of the code I've ever
       | written is GPL. But there are plenty of projects for which I
       | would prefer a different license.
        
       | [deleted]
        
       | tuxxy wrote:
       | With all the great encryption utilities like age[0], Signal, or
       | Veracrypt, can anyone please tell me what the point is in using
       | pgp anymore? It's old, it's clunky, it requires careful use to be
       | safe.
       | 
       | Why not use something more modern?
       | 
       | 0. https://github.com/FiloSottile/age
        
         | brnt wrote:
         | I am going to be sending email long after those tools are gone,
         | and for the time being, the only option for securing that I
         | have is PGP.
         | 
         | This does not mean I think PGP is great, it just means it is
         | working now, across many MUAs.
        
         | pama wrote:
         | I agree that PGP is clunky. Maybe it's just me, but I often
         | find that modern is the opposite of safe and robust.
        
           | tptacek wrote:
           | I'm not sure where that's the case, but it's certainly not
           | the case with cryptography, where "clunky" means "mired in
           | design decisions made before the era of authenticated
           | cryptography".
           | 
           | To me, "old and clunky" also tends to imply "memory unsafe",
           | or "written in Perl so old that a pipe filter in the wrong
           | place in the input coughs up a shell", or "better make sure
           | nobody's name is O'Connor because that includes SQL
           | metadata", or "lol remember temp file races". But I'm
           | prepared to concede that there may be places where the old
           | stuff is better than the new, and eager to hear examples.
        
             | JoachimSchipper wrote:
             | cperciva's spiped is, at least, deliberately old-fashioned;
             | and I'd be inclined to trust it over _most_ newer designs.
             | (Wireguard does appear to be pretty awesome.)
             | 
             | I do agree that lots of legacy cryptosystems just aren't
             | very good.
        
             | pama wrote:
             | Thanks very much for the additional depth on what "old and
             | clunky" could mean in cryptography. I am no expert in this
             | area, and I agree that all these nightmare scenarios you
             | mention (and many more, I'm sure) are very concerning. I
             | prefer to use old (tested and tried) Unix/BSD tools for
             | interactive development rather than their latest rewrites
             | or modern GUIs. In drug design, I'd rather have a clearly
             | understood 30-year-old assay with known failure modes
             | rather than the latest promising experiment that may still
             | have unknown failure modes. But generally speaking, I am a
             | sucker for new tech and I seem to never learn to stop
             | playing with new shiny toys. In a field with explosive
             | growth field, like machine learning, at least I can use the
             | benchmarks against the state of the art to help me decide
             | how or when to advance technologies (every month or so, it
             | seems). So.. is it worthwhile to learn to use age?
        
             | tialaramex wrote:
             | My 10Mbps hub (yes, not a switch) has been with me for
             | decades. I've owned lots of smarter (switched, managed) and
             | faster (100Mbps and then 1Gbps) devices that used less
             | power (turns out when 10Mbps was invented nobody cared
             | about "power saving"...) but over the years lots of those
             | have dropped dead whereas the 10Mbps hub still works, which
             | is why I still own it even though it isn't currently wired
             | up, I know that sooner or later a 1Gbps switch will die and
             | I'll hook that 10Mbps hub in there until a new one arrives.
             | 
             | Now, is it "better"? Overall, no. Or else I wouldn't keep
             | buying Gigabit switches. But is it _more robust_? Yes. And
             | if that 's what you care about...
        
         | thayne wrote:
         | compatibility. Many existing systems, including secure email
         | and packaging systems such as apt use PGP keys.
         | 
         | Sure in theory you could encrypt your email with age, but how
         | many clients support that flow? How do you distribute the
         | public keys?
         | 
         | Part of the point of sequoia as I understand it is to make PGP
         | a little less clunky and easier to use safely.
        
         | deknos wrote:
         | stop with that FUD. PGP is a standard and an implementation.
         | You can have secure (Open)PGP implementation. at least there's
         | a official spec, which is not there for age, which complicates
         | reimplementation
        
         | creamytaco wrote:
         | Signal and veracrypt are not PGP replacements, not even
         | remotely close.
         | 
         | Regarding age, one reason is that it only supports a small
         | fraction of PGP functionality thus useless for many real world
         | applications. Another is that it operates on top of a
         | fundamentally different model and for many folks that model is
         | worse and potentially less secure than PGP's if you try to
         | replicate PGP functionality by composition [1].
         | 
         | Modern doesn't necessarily equal good. PGP is mature and solid
         | which is why it's still widely used and remains popular.
         | 
         | [1] https://neilmadden.blog/2019/12/30/a-few-comments-on-age/
        
       | aborsy wrote:
       | Great!
       | 
       | Perhaps coincidentally, on PGP 30th birthday!
        
         | _hyn3 wrote:
         | Not a coincidence -- in the first paragraph! :)
        
       ___________________________________________________________________
       (page generated 2021-06-08 23:01 UTC)