nwalfield · HackerTrans

nwalfield

no profile record

Submissions

Sequoia PGP: sq JSON: first sketch

sequoia-pgp.org

2 pointsby nwalfieldقبل 4 سنوات0 comments

The Future of Sequoia PGP

sequoia-pgp.org

3 pointsby nwalfieldقبل 5 سنوات0 comments

Sequoia PGP is now LGPL 2.0

sequoia-pgp.org

113 pointsby nwalfieldقبل 5 سنوات64 comments

Yes, We Want Cryptographic Protection for Email

sequoia-pgp.org

54 pointsby nwalfieldقبل 5 سنوات4 comments

PGP Marks 30th Anniversary

philzimmermann.com

11 pointsby nwalfieldقبل 5 سنوات0 comments

Hello, OpenPGP CA

sequoia-pgp.org

77 pointsby nwalfieldقبل 5 سنوات11 comments

Towards Sequoia OpenPGP v1.0

sequoia-pgp.org

83 pointsby nwalfieldقبل 6 سنوات59 comments

Certificate Flooding, SKS and GnuPG Issues, and the Sequoia Project

sequoia-pgp.org

3 pointsby nwalfieldقبل 7 سنوات0 comments

Sequoia PGP: At the Tree Nursery, First Impressions

sequoia-pgp.org

2 pointsby nwalfieldقبل 7 سنوات0 comments

Sequoia PGP: The Seeding Sees the Light of Day

sequoia-pgp.org

50 pointsby nwalfieldقبل 8 سنوات4 comments

Sequoia: A Cool OpenPGP Library

youtube.com

1 pointsby nwalfieldقبل 8 سنوات0 comments

Sequoia, a new OpenPGP implementation in Rust

reddit.com

2 pointsby nwalfieldقبل 8 سنوات1 comments

GnuPG Fundraising Rally

gnupg.org

1 pointsby nwalfieldقبل 9 سنوات0 comments

Op-ed: Why I’m not giving up on PGP

arstechnica.co.uk

6 pointsby nwalfieldقبل 10 سنوات1 comments

Securing the future of GnuPG

gnupg.org

3 pointsby nwalfieldقبل 12 سنة0 comments

GnuPG and g10code

gnupg.org

5 pointsby nwalfieldقبل 12 سنة0 comments

Lenovo Thinkpad repair nightmare – help

reddit.com

3 pointsby nwalfieldقبل 12 سنة0 comments

The Alice and Bob After Dinner Speech (1984)

downlode.org

52 pointsby nwalfieldقبل 12 سنة10 comments

FTP Server at LSUHealth New Orleans

samsclass.info

342 pointsby nwalfieldقبل 12 سنة95 comments

30c3: To Protect And Infect, Part 2 (New Snowden revelations from Applebaum)

youtube.com

21 pointsby nwalfieldقبل 13 سنة1 comments

comments

قبل 5 سنواتdiscuss

1. Unfortunately, the draft is progressing much slower than many people would like. This is partially because not all parties agree on the best way forward for a number of technical decisions that need to be made including AEAD. See for instance this discussion: https://mailarchive.ietf.org/arch/browse/openpgp/?gbt=1&inde...

Happily, the group was rechartered at the beginning of this year and the charter is more narrow (just a cryptographic refresh). So, I'm hopeful that we'll see a new version of OpenPGP in the near future.

2. I present some evidence that pgp is effective against powerful adversaries despite its bad UX in my blog post.

We (Sequoia PGP) are working on improving the UX. Currently we are focused on the plumbing. We have a library, which we put a lot of effort into making not only feature completely, but also safe. We spent a lot of time thinking about the API usable and how to make it secure by default. We're working our way up the stack with tools like Hagrid (which powers keys.openpgp.org) and OpenPGP CA (https://openpgp-ca.org), a tool for administering in-house, federated CAs.

3. If I thought the project I was working on was doomed, I'd stop :D.

قبل 5 سنواتdiscuss

Not yet, but it is on the road map!

قبل 5 سنواتdiscuss

Sequoia does not (yet) have feature parity with GnuPG.

Several important components are missing including a public key store. In GnuPG, the public key store is mandatory. In our discussions with application developers, in particular, developers working on server software, this requirement was more of a hindrance than a help. Thus, in Sequoia we decided it needs to be as easy to bring your own key store (e.g., an existing database) as to use ours.

That said, on the desktop, it is quite useful to have a shared key store--you don't want to import keys into each of your OpenPGP-using applications. We hope to finish our [public key store](https://docs.sequoia-pgp.org/sequoia_store/index.html) this year along with other features that end users need and expect.

قبل 5 سنواتdiscuss

Sequoia consists of a number of components. There is the low-level crate. We released version 1.0 of that in Dec. 2020. There is sq, the CLI tool. We released that a few weeks ago. We've barely started work on the high-level interface.

Just because we plan to write a high-level tool, doesn't mean the low-level crate is hard to use. On the contrary, our experience is that it is pretty easy to use and actually does a good job hiding a lot of the low level details that don't need to be tweaked. For instance, I ported the pep engine from gpgme (GnuPG's high-level interface) to Sequoia's low-level interface. The initial port required about half as many lines of code.

قبل 5 سنواتdiscuss

Right. The sq cli does not have an subcommand to add new subkeys to an existing certificate. But it can use such certificates, and when it generates a certificate, it, by default, generates a certificate with subkeys.

This functionality will, of course, be added to sq (it is possible to do this using the library). We just haven't gotten to it yet. It's not that the functionality is hard to implement. But, we want to have a clean CLI, and there are many possible options. We want to expose them in a sensible way that does not overwhelm the user.

قبل 5 سنواتdiscuss

I think you've misunderstood something. sq has no problem generating certificates with subkeys. Here's the default structure. Notice that we actually include a separate signing subkey by default. This makes it harder to use a data signature where e.g. a self signature is expected and vice verse. This can help protect against some collision attacks, among others.

  $ sq key generate -u '<[email protected]>' --export /tmp/alice.pgp; sq inspect /tmp/alice.pgp
  /tmp/alice.pgp: Transferable Secret Key.
  
      Fingerprint: 99E2 68B5 F5A2 45E9 4A9F  A1FB F10A BDD2 C1BC 2478
  Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
  Public-key size: 256 bits
       Secret key: Unencrypted
    Creation time: 2021-02-15 21:34:45 UTC
  Expiration time: 2024-02-16 15:01:06 UTC (creation time + P1095DT62781S)
        Key flags: certification
  
           Subkey: E54F CB2B 4619 FDB9 680A  974C 94D7 9D77 395B 8A7C
  Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
  Public-key size: 256 bits
       Secret key: Unencrypted
    Creation time: 2021-02-15 21:34:45 UTC
  Expiration time: 2024-02-16 15:01:06 UTC (creation time + P1095DT62781S)
        Key flags: signing
  
           Subkey: 62BF 9E6B C022 D3FB 681F  5279 2B09 341C EDFE 0AF9
  Public-key algo: ECDH public key algorithm
  Public-key size: 256 bits
       Secret key: Unencrypted
    Creation time: 2021-02-15 21:34:45 UTC
  Expiration time: 2024-02-16 15:01:06 UTC (creation time + P1095DT62781S)
        Key flags: transport encryption, data-at-rest encryption
  
           UserID: <[email protected]>

قبل 8 سنواتdiscuss

We've been considering this, but we'd rather have people use the library. We already have the start of a Python interface, which is pretty easy to use, IMHO.

But, I suspect that some people will insist on a shell script. So, we'll probably go this route sooner rather than later to avoid developers trying to parse the output of sq in an ad-hoc manner.

قبل 8 سنواتdiscuss

What would make a friendly interface in your opinion?

The sq frontend uses git style subcommands to clearly separate actions from options. This is something that gpg doesn't do too well. For instance, commands (e.g., -e) look like options (e.g., -r). If no command is given, gpg tries to guess what you meant, which is perhaps good for users, but bad for programmers. And if an option isn't relevant to a command, it is often just ignored, which again, is perhaps reasonable for users, but bad for programmers.

قبل 8 سنواتdiscuss

Let's go through Matt's major points:

    Key Exchange / Key Management

This isn't really a problem with the OpenPGP protocol or an OpenPGP implementation. This is inherent to any system that tries to protect you from active adversaries. If you are willing to use centralization, then you can do something like X509 (what is what TLS uses), but there are many, many cases of CAs issuing bad certificates either by accident or maliciously, e.g., the TURKTRUST incident. You can also do something like Signal with its verified key servers. But, if you want to be decentralized, then somehow you have to get the user involved. So, in my opinion, this is more a criticism of decentralization than of OpenPGP.

Now, that doesn't mean that OpenPGP tooling can't help. In fact, about 4 years ago, several initiatives began working on mechanisms to make key discovery much easier, and mostly transparent for users primarily concerned about privacy (as opposed to those whose threat model includes active adversaries, like activists, lawyers, or journalists). See, in particular, the work that pep (https://pep.foundation) and Autocrypt (https://autocrypt.org) have been doing.

    Forward Secrecy

As I've written before (https://arstechnica.com/information-technology/2016/12/signa...), I don't think that forward secrecy is actually fixing a problem that most people have. Particularly in the case of OpenPGP where most people are interested in encryption of data at rest (messages stored on an IMAP server), which forward secrecy doesn't help (forward secrecy, because it throws away old key material, only makes sense for protecting data in motion).

But, that doesn't mean that we haven't given some thought to the problem. In fact, at the very same gathering, Justus, who is also working on Sequoia, presented a proposal for adding forward secrecy to OpenPGP in a backwards compatible manner. You can watch the presentation (https://www.youtube.com/watch?v=an6oYjikAPY), or read an early version of the proposal (https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGf...).

The short version is: OpenPGP already has mechanisms to mark encryption keys as being appropriate for data at rest or data in motion. Until now, no implementation has bothered with this distinction. We propose creating two encryption-capable subkeys, one for data at rest, and one for data in motion, and rotating the one for data in motion once a week. To ensure that a sender has a non-expired encryption key we pre-generate keys, and distribute them via the keyserver network.

    The OpenPGP format and defaults suck

It is true that OpenPGP has standardized a number of ciphers that are no longer sensible, includes compression support, etc. But, OpenPGP is over 30 years old. In that time there have been many improvements. But Matt is right that these improvements come slowly. This is partly due to the lack of funding: the industry choose S/MIME over OpenPGP. (Although S/MIME is cryptographically worse than OpenPGP. See EFAIL for a critical example of why.)

A major difficult to deprecating old ciphers is that OpenPGP is used for data at rest. And people rightly expect, I think, to be able to decrypt data and verify signatures from X years ago. This means we can't completely drop support for, say, CAST5: people wouldn't be able to decrypt old messages. Matt seems to ignore this bit, and focuses primarily on real-time communication (e.g., Signal), which only needs encryption for data in motion, i.e., the encryption is stripped and only archived on a trusted device (e.g., not an IMAP server).

One thing that we are consider in Sequoia is requiring the caller to provide a timestamp when verifying or decrypting a message. The timestamp can be used to choose defaults that are appropriate for when the message was allegedly created. The timestamp can be double checked with the timestamp in the signature. In this way, if someone tries to send you an email using a deprecated cipher, they'll also have to set the timestamp in the email to, say, 1997, which would hopefully be suspicious. Likewise, something like a can be shown when the message doesn't meet the current standard.

I hope that helps! If you have any other questions, you're welcome to ask here, or on irc (#sequoia on freenode) or on our mailing list ([email protected]).

:) Neal

قبل 8 سنواتdiscuss

While at the Delta X gather last week, we recorded an introduction to Sequoia. The presentation covers our motivation for starting the project, an overview of Sequoia’s architecture, and the project’s status: https://www.youtube.com/watch?v=NBbtIZipeNI

The tl;dr is that we’re actually pretty far: Sequoia is already being tested with the p≡p engine, and other projects, like Delta Chat, have begun replacing GnuPG or NetPGP with Sequoia.

قبل 10 سنواتdiscuss

One way to reduce the cost of cross CPU synchronization is to use sloppy reference counters:

"An Analysis of Linux Scalability to Many Cores" (https://pdos.csail.mit.edu/papers/linux:osdi10.pdf)

قبل 10 سنواتdiscuss

Taler is quite different from, say, bitcoin in that it tries to enable taxation while preserving anonymity. The main webpage has more info: https://www.taler.net/ . Unfortunately, it doesn't appear that a paper has been published yet. But, there are a couple of presentations at https://taler.net/news .

قبل 10 سنواتdiscuss

He is listed by Tanja Lange as one of her PhD students: http://www.hyperelliptic.org/tanja/

قبل 10 سنواتdiscuss

Check out sloppy counters: https://pdos.csail.mit.edu/papers/linux:osdi10.pdf

قبل 10 سنواتdiscuss

The author unfortunately doesn't understand how GC works:

> GC’s overhead relates to the total memory allocated, not just > the memory actively used in the code. Each new allocation > results in an increased time per scanning cycle. Certainly > there are many optimizations involved in a good GC to limit > this, but the fundamental relationship is still linear. As a > program uses more memory the overhead of it’s GC increases.

A GC's overhead (at least a mark and sweep collector) is proportional to the number of live objects. This is because all of the dead objects are unreachable and thus aren't scanned.

قبل 11 سنةdiscuss

set -o pipefail makes common idioms a pain. Consider using head, which simply exits after it has read a few lines. In this case, the input process gets a SIGPIPE and exits with a non-zero exit code:

Consider /tmp/test.sh:

  set -o pipefail
  yes foo | head

  $ bash /tmp/test.sh >/dev/null
  $ echo $?
  141

قبل 12 سنةdiscuss

This is a complicated story. The BND's priorities have changed (they are now migrating to Windows internally instead of GNU/Linux). FOSS is also a lower priority. See this video from the German Bundestag about funding GPG and related projects: http://vimeo.com/111715711 . (TLDR: We already gave them some money. Others should step in and cover the bill.)

قبل 12 سنةdiscuss

I tried that trick and it didn't work for me (I still get the paywall). Too bad.

قبل 12 سنةdiscuss

This post is disingenuous. In particular:

  [Cloud Operating Systems] enable the vision of light and fast application servers, while preserving the superior security and flexibility of true hypervisors.

Hypervisors are only secure if you don't need any sharing. If you have two applications running as separate guests and they need to exchange data, then all of the security issues that you'd have on a normal OS return, but they are harder to solve, because the Hypervisor doesn't provide much support!

As an extreme case, consider running all of your applications on your Desktop in their own VM. Now, you are in your web browser and you download a Word document that you want to edit. Somehow, you have to transfer this document to the Word Processor VM to edit it (they have different file systems so you need to use something like scp). If, after you're done editing it, you need to send it to someone via email, then you'll have to copy it to the Email VM. It's not how to see how this seriously impacts usability!

When sharing is required, then a Hypervisor is not helpful. That's not to say that Hypervisors are useless, as the author claims his opponents say. Hypervisors are good for running different operating systems on the same hardware and they are good at isolating the different OSes from each other. However, once any sharing is required, hypervisors are not the right tools for the job.

قبل 12 سنةdiscuss

An unguessable ID that designates some resource is called a (crypto) capability.

Capabilities are quite different from access control lists (ACLs). In an ACL system, the list of authorized principals is attached to the resource. Thus, sharing access to a resource requires updating the resource. For instance, if Alice creates a document and wants to share it with Bob, then Bob needs an account and Alice needs to add Bob to the document's ACL. In a capability system, the capabilities designate the resource and sharing the resource is as simple as copying the capability. In fact, Bob can also share the document (without copying it first) with Carol. In an ACL system, Bob would not typically have permission to update the ACL.

For more information about capabilities, start with, for instance, the e-rights wiki at http://erights.org/elib/capability/index.html .