1. 3

    Having worked with PGP for years, I think S/MIME makes more sense for 95% of the cases. We need something like LetsEncrypt but for S/MIME with similar challenge-types. S/MIME class > 1 provides authentication (e.g. you present your passport to the CA or something), but we don’t really need that in most cases (just like we don’t really need extended validation (EV) certificates in SSL in most cases). S/MIME class 1 is enough as it simply validates the “From”-address on the one hand and allows end-to-end-encryption on the other.

    Of course, if you lose your key, you won’t be able to decrypt your stuff, but that’s obvious, isn’t it? One possibility is to do it like Matrix, where you can store all your keys on a server but protect them with a passphrase. Those too paranoid for that won’t have to, though, but I’m talking about the 95%.

    1. 2

      You can have CAs in the PGP ecosystem as well. CAcert operates one, as did/does gswot.

      1. 2

        Neither of which have worked out. I have been a CACert Assurer since 2014, where there was still some momentum in hopes of getting the CACert root into OS and browser certificate stores. Let’s be honest, people only wanted CACert, because it was free. When LetsEncrypt entered the scene, CACert became irrelevant. I only knew of one site that used the cert, which was https://tedunangst.com/, and he also switched to LetsEncrypt. For all practical purposes, CACert is dead.

        The Gossamer Spider Web of Trust (GSWoT) not only is dead, it never left the ground. First, the GSWoT website doesn’t support HTTPS, which let’s be honest, has been unacceptable for several years now. Second, links to news.gmane.org mailing lists, both for the project, and the PGP Basics list went offline mid 2016. Finally, the project launched in 2007, and between then and 2012, has only managed to secure 39 Introducers, and sign 56 PGP keys.

        Personal experience with GSWoT, I had a phone call from Stephen Weber himself in 2014. I was not a CACert Assurer, nor a notary public (I am both now). As such, the only way to become a GSWoT Introducer was to get my key signed by 3 Introducers. Except there are no Introducers close to where I live, which would require significant travel. This seemed a bit unrealistic for a brand new project unless you were part of the founding group of members.

        My key 0x22EEE0488086060F (created in 2004) was already in the PGP Strong Set, and ranked well. None of the Introducers at that time we’re in the Strong Set, which seemed to be problematic. So I reached out with an application, and asked if an exception could be made for me. Stephen called me, and was cordial, but wanted to make it clear that GSWoT wasn’t some sort of exclusive boys club. If I wanted to be an Introducer, I had to go through the outlined process.

        I understand protecting the integrity of the project and Introducers. I’ve since held many PGP key signing parties since that phone call, some of them with over 200 participants. I could have been very influential in introducing the project, but their strict application process prevented me from becoming part of it.

        It’s been several years since that phone call, and very little to nothing has changed with the project.

        1. 1

          That’s and interesting perspective, thanks. By the time I took over gswot (sorry I don’t specifically remember our call) it had been running successfully for some time but interest had waned. I was trying to keep it on life support, but honestly I think I’m the only one who cared much which is why I ended up as admin. The project isn’t completely dead, but there probably wasn’t room for a second community CA. As you say, even the bigger one (CAcert) is mostly only useful for pgp now and the PGP community has never been into CAs so that’s downhill too.

          My point in my comment wasn’t that we should resurrect these particular community CAs, but that we don’t need to switch tech to get a different PKI model. If you want CAs in pgp land, the tech does it great, just someone needs to want it :)

          1. 1

            The CACert statistics show that interest has certainly waned. Unfortunately, CACert has some legitimate security problems:

            • Its own website uses its own CA for HTTPS, which browsers don’t trust. As such, the connection is not secure.
            • CACert accounts do not support 2FA, which definitely should, given the legal ramifications of certificate assurance.
            • CACert still signs PGP keys with SHA-1, despite a published attack on this specific use case.

            Also, I went through my email, and it appears I made my Introducer application in 2014, not 2011 as my memory seems to recall. I updated my reply.

    1. 1

      A properly identified match is first based on an email match and then a match between the bcrypt hashes for the passwords of those email matches.

      Nice. Pinterest uses bcrypt for password hashing.

      1. 3
        1. Despite training, email recipients will reply in plaintext. MUAs make doing anything else very difficult.
        2. Even if the body of the email is properly encrypted, the mail headers are not. Senders announce the contents of the encrypted mail all the time in the subject, never mind the rest of the header data is plaintext.
        3. OpenPGP keys are not forward secret. Any and all past intercepted encrypted emails can and will be broken when your OpenPGP key is compromised.
        4. DKIM provides transparent non-repudiation (accidentally, interestingly enough), making OpenPGP and S/MIME signing of emails unnecessary.
        5. OpenPGP’s AEAD construction via its home-brew MDC is broken.
        6. Email cannot be secured as demonstrated via EFAIL. The mitigation is either to suppress loading active content in your email, or remove OpenPGP or S/MIME plugins from your MUA, and process the encrypted content out-of-band.
        1. 1

          Email cannot be secured as demonstrated via EFAIL.

          That feels like an exaggeration.

          I guess the main problem is that most users are not willing to spend resources in improving the security ecosystem, be it in form of money or volunteer work. Which leads to central software being critical to our security being understaffed and insufficiently maintained.

        1. 11

          My number one worry with encrypted email is that I will lose access to it permanently.

          My number two worry with encrypted email is that nobody uses it so there’s no point.

          My number three worry is traffic analysis, but it’s a long way behind one and two.

          1. 8

            I’ve created so many public keys over the years because some thing (like the Ubuntu CoC or “signed” commits in GitHub) requires it and I’ve lost access to literally every one of them, mostly because I use a public key about once every five years. I would literally never set up email encryption because of your reason number one.

            1. 16

              What doesn’t help is the relative opaqueness of how gpg and its “keyring” works. With ssh it’s easy: I just have a ~/.ssh/id_ed25519 and ~/.ssh/id_ed25519.pub file, and public keys for verification are in ~/.ssh/authorized_keys. That’s pretty much all there’s to it.

              I’ve never lost access to a ssh key or been confused how this works. With gpg it’s so much harder.

              1. 5

                I agree with this so, so much. SSH is almost trivial to understand, and there are even concrete benefits to setting it up and using it!

                1. 10

                  It’s simple to use for simple cases but a bunch of things are complicated with SSH, for example:

                  • If a key is compromised, how do I revoke access to it from all of the machines that have it in their authorised-keys file?
                  • If I want to have one key per machine, how do I add that key to all of the machines I want it to access?
                  • How do I enforce regular key rollover?

                  You can do these things with PKI but now your key management is both complicated and very different from ‘normal’ SSH.

                  SSH is also solving a much simpler problem because it only needs to support the online use case. If I connect to a machine with SSH and it rejects my key, I know immediately and it’s my problem. The protocol is interactive and will try any keys I let it, so I can do key rollover by generating a new key, allowing SSH to use both, and eventually replacing the public key on every machine I connect to with the new one. If I send an encrypted email with the wrong key, the recipient gets nonsense.

                  The offline design is the root cause of a lot of the problems with email. It was designed for a world where the network was somewhat ad-hoc and most machines were disconnected. When my father’s company first got Interne email, they ran an internal mail server with a backup MX provided by their ISP. When someone sent an email, it would go to their ISP, when they dialed in (with a modem, which they did every couple of hours) the backup MX would forward email to them and they’d send outgoing mail, which would go via the same multi-hop relaying process. Now, email servers are assumed to be online all of the time and it would be completely fine to report to the sender’s mail client if the recipient’s mail server is not reachable and ask them to try again later. If you define a protocol around that assumption from the start, it’s completely fine to build an end-to-end key-exchange protocol in and a huge number of the problems with encrypted email go away.

                2. 1

                  With SSH however, it’s trivial to create a new key, and get it installed on the new server. Because SSH keys don’t worry about a decentralized “web of trust” in way OpenPGP does, there is no historical or technological baggage to require you carrying around your SSH keypair. I’ve been through so many SSH keys over the years on personal and corporate systems, yet never once has it ever bothered me.

                3. 8

                  This is one reason I started signing every email I send years ago and also how sign every git commit. It forces my key to be a core part of my workflow

                  1. 3

                    Similarly, I also use gpg to encrypt documents, and to encrypt passwords in pass. You’ll also rarely need to interact with it for Arch packages. Can’t beat its ubiquity.

                  2. 2

                    If you want you can make a “master” key that you keep in one place permanently and at backup locations, and then sign stuff with subkeys signed by the master key. That way you will never lose anything if you lose a subkey but not the masterkey. Not a great solution but still helpful

                1. 2

                  When do all their mirrors support https? Downloading something over http or even ftp does not feel like 2021.

                  1. 12

                    If they do this right (signed packages and so on), then https will only help with privacy. Which is important for sure, but leaking which packages you download is less horrible than leaking the contents of your conversations, or even just who you’ve been in contact with lately.

                    1. -1

                      HTTPS is more than just privacy. It also prevents JavaScript injection via ISPs, or any other MITM.

                      1. 21

                        It does that for web pages, not for packages. Packages are signed by the distro’s keys, so if anyone were to mess with your packages as you download them, your package manager would notice and prevent you from installing the package. The only real advantage to HTTPS for package distribution is that it helps conceal which packages you download (though even then, I get an attacker could get a pretty good idea just by seeing which server you’re downloading from and how many bytes you’re downloading).

                        1. 1

                          It does that for web pages, not for packages

                          Indeed, however ISOs, USB installers, etc. can still downloaded from the web site.

                          Packages are signed by the distro’s keys, so if anyone were to mess with your packages as you download them, your package manager would notice and prevent you from installing the package.

                          Yes, I’m familiar with cryptographic signatures.

                          1. 9

                            Indeed, however ISOs, USB installers, etc. can still downloaded from the web site.

                            Yes. The Debian website uses HTTPS, and it looks like the images are distributed using HTTPS too. I thought we were talking bout distributing packages using HTTP vs HTTPS. If your only point is that the ISOs should be distributed over HTTPS then of course I agree, and the Debian project seems to as well.

                            1. 0

                              No, the point is that there is no need for HTTP when HTTPS is available. Regardless of traffic, all HTTP should redirect to HTTPS IMNSHO.

                              1. 16

                                But… why? Your argument for why HTTPS is better is that it prevents JavaScript injection and other forms of MITM. But MITM clearly isn’t a problem for package distribution. Is your argument that “HTTPS protects websites against MITM so packages should use HTTPS (even thought HTTPS doesn’t do anything to protect packages from MITM)”?

                                I truly don’t understand what your reasoning is. Would you be happier if apt used a custom TCP-based transport protocol instead of HTTP?

                                1. 6

                                  I suspect that a big reason is cost.

                                  Debian mirrors will be serving an absurd amount of traffic, and will probably want to serve data as close to wire speed as possible (likely 10G). Adding a layer of TLS on top means you need to spend money on a powerful CPU or accelerator kit, instead of (mostly) shipping bytes from the disk to the network card.

                                  Debian won’t be made of money, and sponsors won’t want to spend more than they absolutely have to.

                                  1. 4

                                    But MITM clearly isn’t a problem for package distribution.

                                    It is though! Package managers still accept untrusted input data and usually do some parsing on it. apt has had vulnerabilities and pacman as well.

                                    https://justi.cz/security/2019/01/22/apt-rce.html

                                    https://xn--1xa.duncano.de/pacman-CVE-2019-18182-CVE-2019-18183.html

                                    TLS would not prevent malicious mirrors in either of these cases, but it would prevent MITM attacks exploiting these issues.

                                    1. 7

                                      Adding TLS implementations also bring bugs, including RCE. And Debian is using GnuTLS for apt.

                                      1. 1

                                        Idd. It was one of the reasons for OpenBSD to create signify so I’m delighted to see Debians new approach might be based on it.

                                        From https://www.openbsd.org/papers/bsdcan-signify.html:

                                        … And if not CAs, then why use TLS? It takes more code for a TLS client just to negotiate hello than in all of signify.

                                        The first most likely option we might consider is PGP or GPG. I hear other operating systems do so. The concerns I had using an existing tool were complexity, quality, and complexity.

                              2. 7

                                @sandro originally said: “When do all their mirrors support https?” Emphasis on “mirrors”. To the best of my knowledge, “mirror” in this context does not refer to a web site, or a copy thereof, but to a packages repository.

                                I responded specifically in this context. I was not talking about web sites, which rely on the transport mechanism for all security. In the context I was responding to, each package is signed. Your talk of JavaScript injection and other MITM attacks is simply off topic.

                        2. 9

                          ftp.XX.debian.org are CNAMEs to servers accepting to host a mirror. These servers are handled by unrelated organisations, so it is not possible to provide a proper cert for them. This match the level of trust: mirrors are not trusted with the content nor the privacy. This is not the case of deb.debian.org which is available over HTTPS if you want (ftp.debian.org is an alias for it).

                          1. 2

                            Off line mirrors, people without direct internet access, decades later offline archives, people in the future, local DVD sets.

                            Why “trust” silent media?

                          1. 3

                            I have nothing ill to say of this project, but if you’re looking for a condemnation of the OpenPGP ecosystem, look no further than the encrypt() function definition here.

                            /**
                             * Encrypts message text/data with public keys, passwords or both at once. At least either encryption keys or passwords
                             *   must be specified. If signing keys are specified, those will be used to sign the message.
                             * @param {Object} options
                             * @param {Message} options.message - Message to be encrypted as created by {@link createMessage}
                             * @param {PublicKey|PublicKey[]} [options.encryptionKeys] - Array of keys or single key, used to encrypt the message
                             * @param {PrivateKey|PrivateKey[]} [options.signingKeys] - Private keys for signing. If omitted message will not be signed
                             * @param {String|String[]} [options.passwords] - Array of passwords or a single password to encrypt the message
                             * @param {Object} [options.sessionKey] - Session key in the form: `{ data:Uint8Array, algorithm:String }`
                             * @param {Boolean} [options.armor=true] - Whether the return values should be ascii armored (true, the default) or binary (false)
                             * @param {Signature} [options.signature] - A detached signature to add to the encrypted message
                             * @param {Boolean} [options.wildcard=false] - Use a key ID of 0 instead of the public key IDs
                             * @param {Array<module:type/keyid~KeyID>} [options.signingKeyIDs=latest-created valid signing (sub)keys] - Array of key IDs to use for signing. Each `signingKeyIDs[i]` corresponds to `signingKeys[i]`
                             * @param {Array<module:type/keyid~KeyID>} [options.encryptionKeyIDs=latest-created valid encryption (sub)keys] - Array of key IDs to use for encryption. Each `encryptionKeyIDs[i]` corresponds to `encryptionKeys[i]`
                             * @param {Date} [options.date=current date] - Override the creation date of the message signature
                             * @param {Array<Object>} [options.signingUserIDs=primary user IDs] - Array of user IDs to sign with, one per key in `signingKeys`, e.g. `[{ name: 'Steve Sender', email: 'steve@openpgp.org' }]`
                             * @param {Array<Object>} [options.encryptionUserIDs=primary user IDs] - Array of user IDs to encrypt for, one per key in `encryptionKeys`, e.g. `[{ name: 'Robert Receiver', email: 'robert@openpgp.org' }]`
                             * @param {Object} [options.config] - Custom configuration settings to overwrite those in [config]{@link module:config}
                             * @returns {Promise<MaybeStream<String>|MaybeStream<Uint8Array>>} Encrypted message (string if `armor` was true, the default; Uint8Array if `armor` was false).
                             * @async
                             * @static
                             */
                            export async function encrypt({ message, encryptionKeys, signingKeys, passwords, sessionKey, armor = true, signature = null, wildcard = false, signingKeyIDs = [], encryptionKeyIDs = [], date = new Date(), signingUserIDs = [], encryptionUserIDs = [], config, ...rest }) {
                            

                            So simple, even Johnny can encrypt. (Surely nothing could go wrong!)

                            Contrast this with age.

                            1. 2

                              age is the obvious replacement for OpenPGP, but it doesn’t have a JavaScript implementation (that I’ve found at least). Possibly a better replacement than OpenPGP.js would be TweetNaCl.js by Dmitry Chestnykh.

                              export const encrypt = (json, key) => {
                                const keyUint8Array = decodeBase64(key);
                              
                                const nonce = newNonce();
                                const messageUint8 = decodeUTF8(JSON.stringify(json));
                                const box = secretbox(messageUint8, nonce, keyUint8Array);
                              
                                const fullMessage = new Uint8Array(nonce.length + box.length);
                                fullMessage.set(nonce);
                                fullMessage.set(box, nonce.length);
                              
                                const base64FullMessage = encodeBase64(fullMessage);
                                return base64FullMessage;
                              };
                              
                              1. 1

                                At the risk of self-promotion, I did provide a JS alternative that’s better than TweetNaCl on two fronts:

                                1. Type-safety (keys are distinct types rather than just Uint8Arrays).
                                2. Supports additional authenticated data (e.g. for context-binding for ciphertexts).

                                It also handles encoding for you.

                                1. 1

                                  Fair enough. However, to be a touch critical if I may, does Dhole Cryptography have an audit report? TweetNaCl.js was audited by Cure53 in 2017, and from the audit (also on the GitHub README):

                                  The overall outcome of this audit signals a particularly positive assessment for TweetNaCl-js, as the testing team was unable to find any security problems in the library. It has to be noted that this is an exceptionally rare result of a source code audit for any project and must be seen as a true testament to a development proceeding with security at its core.

                                  To reiterate, the TweetNaCl-js project, the source code was found to be bug-free at this point.

                                  […]

                                  In sum, the testing team is happy to recommend the TweetNaCl-js project as likely one of the safer and more secure cryptographic tools among its competition.

                                  Compare that to the audit of OpenPGP.js which appears to still have outstanding issues, or the wiki is out of date.

                                  1. 1

                                    Dhole Cryptography wraps sodium-plus, which defers to libsodium.js (or sodium-native if you install it alongside). Libsodium.js is compiled from libsodium, while sodium-native is an FFI wrapper for libsodium. Libsodium has been audited.

                                2. 1

                                  age is the obvious replacement for OpenPGP

                                  Actually it would be more technically correct to say that age is a replacement for a subset of OpenPGP.js. For example, as far as I can see from the readme, age doesn’t sign encrypted files thus you can’t be sure who created the signed file. Age cannot be used to sign software binaries (for example). Age’s specification is a google doc compared to OpenPGP.js that is based on an IETF standard.

                                  1. 1

                                    True. age only supports encryption and decryption. It does not do any signing. For that, you should use minisign or signify.

                                    1. 1

                                      Yes, age for encryption/decryption, minisign/signifty for signing/verification. What should we use for key authentication though?

                                      OpenPGP.js allows building something like this: https://keyoxide.org/9f0048ac0b23301e1f77e994909f6bd6f80f485d where one can get more assurance that the key belongs to the person they think it should in an automatic, machine-readable way.

                                        1. 1

                                          I’m not familiar with Keyoxide, but it seems similar to Keybase and keys.pub. In practice though, the “web of trust” is broken.

                                1. 7

                                  Interesting approach, but I think it’s asking too much of human color perception. So much of the information here is expressed as subtle color variations, which are hard for people to tell apart, especially people with color blindness. I found the arrangements of colors a lot less memorable than shapes (as in hashblot), making it harder to check differences.

                                  I think Urb*t has another pretty good scheme.

                                  1. 3

                                    Was going say this. The interactive test on the page makes use of the property that changing a small part of the input creates a totally different hash. Testing this way also makes a traditional hex string representation look very good!

                                    The real question is whether it’s harder or easier to create a similar-enough avatar symbol compared to creating a similar-enough hash string (for example, one where ‘n’ beginning and end characters are the same.)

                                    (I think I’ve seen studies on visually comparing hex strings but the closest I can find is a study showing a 20% error rate when testing people on “are these two 6 digit decimal numbers the same?”. There are studies on the usefulness of alternative hash representations though,for example.)

                                    1. 1

                                      I’m curious to see the translation of SHA-256 hashes (or any arbitrary length number of bits) into sigils. IIRC, there are some peculiarities about their nouns that has to be taken care of first.

                                    1. 5

                                      This is a game changer for me, according to the gron(1) manpage:

                                      The output of gron is valid JavaScript:
                                      
                                          $ gron testdata/two.json > tmp.js
                                          $ echo "console.log(json);" >> tmp.js
                                          $ nodejs tmp.js
                                          { contact: { email: 'mail@tomnomnom.com', twitter: '@TomNomNom' },
                                          github: 'https://github.com/tomnomnom/',
                                          likes: [ 'code', 'cheese', 'meat' ],
                                          name: 'Tom' }
                                      
                                      1. 3

                                        I missed that. It almost certainly explains why things can round-trip so reliably.

                                        1. 2

                                          This is very neat too, thanks for sharing!

                                        1. 17

                                          As a security researcher and cryptography hobbyist, I appreciate that Neovim took out Vim’s unauthenticated and broken Blowfish encryption support. Blowfish is a 64-bit block cipher which is vulnerable to Sweet32. I brought this up to the Vim project, and unfortunately heated emotions took over, and the issue was closed. Further, Vim’s password hashing function for key derivation is weak. This issue remains open.

                                          Regardless, Neovim does not support :X to encrypt data. As such, if you want built-in encrypted text, you’ll either need to use the gnupg.vim plugin, or write something that hooks into an external tool, like OpenSSL.

                                          Edit: spelling

                                          1. 3

                                            Huh, that’s interesting. I didn’t know that was such a contentious ‘issue’ with the vim folks..

                                            1. 4

                                              That was a wild read. Reminds me of the gendered pronouns issue

                                              1. 7

                                                It’s not a contentious issue with Vim users per se. It’s a contentious issue with cryptographers and Bram Moolenaar. But yeah, it’s a bit silly TBH.

                                                1. 11

                                                  I use Vim’s blowfish feature; just for some files that aren’t super-sensitive but also don’t want showing up in a grep or be easily readable for anyone (they would have to get access to my computer first, which is already a significant barrier).

                                                  I dislike using gpg with a passion, and integrating external tools in Vim and doing it well is actually harder than it might seem (though not impossible). Clearly it can all be improved, e.g. by using libsodium or whatnot; actually, it seems there is even a TODO entry for that.

                                                  I’ve seen several discussions about this, and the problem is always the same: people (often actually the same people) will start being caustic, start ranting about blowfish, “brokenness”, “laziness”, etc. and at this point the entire conversation/issue gets sidetracked and you’re no longer talking about how to improve Vim’s crypt feature, the maintainers get exasperated (rightfully so, IMO), and nothing gets done because, basically, “fuck this guy”. This is what happened to your issue, which was fine, but got hijacked by this other guy who used it to rant.

                                                  From a UX point of view, it’s by far the most convenient way to encrypt a text file, and this has a lot of security value too. A number of crypto people tend to hyper-focus on algorithms, and those are not unimportant of course, but it’s just one part of the entire cryptosystem.

                                                  It’s not just Bram who opposes outright removing this feature, other Vim maintainers such as Christian do too.

                                                  tl;dr: someone just needs to make a patch to add libsodium integration instead of ranting about blowfish and it would all be better.

                                                  1. 5

                                                    I just use Mozilla’s sops. It supports a wide variety of key stores and uses $EDITOR.

                                                    1. 3

                                                      I dislike using gpg with a passion

                                                      And for good reason. PGP is littered with problems

                                                      by using libsodium or whatnot; actually, it seems there is even a TODO entry for that.

                                                      This is good news. I wasn’t aware this was on the TODO. Hopefully this comes sooner than later.

                                                      1. 2

                                                        FYI: https://github.com/vim/vim/pull/8394

                                                        Looks like help/advice/feedback is requested, if you’ve got the time and inclination :-)

                                                        1. 1

                                                          This is great! Thanks for doing this!

                                                          I comment on your PR about not replacing the sha256_key() KDF with crypt_pwhash_*. I don’t know if that’s something you plan on addressing or not, but because you reference issue #639, I thought I would mention it.

                                                          1. 2

                                                            It’s not my PR; I just happened to notice it and thought you might be interested 😅

                                                            I did actually work on this a little bit a few weeks ago, but I’m a crappy C programmer and it was more complex than I thought, so I quickly gave up.

                                                            1. 1

                                                              Ah, fair. Thanks for bringing it to my attention regardless. I’ll be following it.

                                            1. 2

                                              #facepalm

                                              A deliberate netsplit between the new ircd and old ircd. Then an apparent netplit within the old ircd cluster. Watching this whole thing implode from the sidelines is really quite remarkable.

                                              1. 3

                                                I’d believe it if somebody told me they convinced them to change the server software without migrating anything on purpose, because this is the biggest self sabotage they could do after all that happened. Why should you stay on freenode when all your channels and accounts (and accounts of friends) are gone..

                                                1. 4

                                                  Why does every vulnerability come with it’s own catchy acronym and slick webpage now?

                                                  1. 8

                                                    Generally easier to remember, identify, and communicate than CVE IDs.

                                                    Are we vulnerable to ALPACA?

                                                    versus

                                                    Are we vulnerable to CVE-2021-31971?

                                                    1. 6

                                                      At least they’re getting more adorable over time!

                                                      1. 6

                                                        Why does every vuln with a name get at least one person asking this exact question?

                                                        1. 3

                                                          Why does every vuln with a name get at least one person asking the question of why every vuln with a name gets at least one person asking why every vuln needs a name now?

                                                        2. 3

                                                          A Bug With A Logo? It worked the first time…

                                                          In fact, thinking back, this trick still worked for POODLE, in the sense of management-level people caring enough to ask about it and organising statements that “we’re now protected against POODLE” or “we’re unaffected by POODLE” etc. But no branded vuln since has had any real boost from its marketing, as far as I recall – nobody cares, just the way everyone discussing this aspect of Heartbleed could foresee right from the start. The marketing has just become this motion you go through because it’s what everyone does.

                                                          1. 2

                                                            Crypto bros are a very weird crowd worried a lot about publicity and street cred.

                                                          1. 1

                                                            I’ve been running Firefox since 0.8, but with that said, it has some usability issues (on Linux at least, such as poor stability with screen sharing under Wayland, curious UI element changes such as breaking the tabbed interface paradigm, etc.), sandbox security concerns, and noticeable performance problems (here’s an old HTML5 speed test for IE 11).

                                                            1. 5

                                                              Bullet journalling has worked really well for me. Coupled with a personal wiki, it’s very powerful. Has anyone else had serious success?

                                                              1. 6

                                                                Yes, it’s great. I’ve been using it for 2,5 years in a manner similar to the article: Not artistic, just minimal and functional.

                                                                1. 2

                                                                  Same here, been using Bullet journals for home and work for about three years, and really like it.

                                                                  I previously had separate written books for work and home, but since Covid am now using a paper journal (small Leuchturm 1917 pocket book) for personal activities, and Emacs journal mode and org mode for work. Mostly because I don’t have the desk space at home to lay out my old work journal, but I’m enjoying being able to quickly take notes in meetings, work with tables, embed links, and keep track of citations from co-workers.

                                                                  1. 2

                                                                    Googling “journal mode” yielded a lot of org-journal links, is that what was meant? I’m curious

                                                                    1. 2

                                                                      Ah, correct, org-journal is the proper name. I had forgotten that it was part of org.

                                                                      1. 1

                                                                        I’m using org-journal for this purpose and it works really well for me. I do use it with a weekly file not separate daily files (for which it is designed it seems) and have each day as a top level org heading.

                                                                    2. 1

                                                                      What do you use for a personal wiki, and how do you take advantage of it with bullet journaling?

                                                                      1. 2

                                                                        I use Roam, mostly. Also, I keep todos and logs in the BuJo but information and such in the Wiki. Does that make any sense?

                                                                        1. 1

                                                                          Yes. Thanks.

                                                                    1. 3

                                                                      I think the clever thing here is that it starts at the abbreviation and then builds a phrase. This makes it very easy to reason about the entropy while still using arbitrary logic to come up with the phrase to be memorized.

                                                                      Of course when you generate 20 and let the user pick one you lose some entropy.

                                                                      1. 2

                                                                        Of course when you generate 20 and let the user pick one you lose some entropy.

                                                                        Good point! This could be fixed by presenting different words for the same set of prefixes, rather than presenting different sets of prefixes. For example, if one of the randomly chosen prefixes was hin, one presentation could display Hinted and another Hindu.

                                                                        Of course, that won’t stop the user from just hitting refresh :)

                                                                        1. 1

                                                                          Of course when you generate 20 and let the user pick one you lose some entropy.

                                                                          Not of any significant value though. If the default security margin is 50 bits (as per the web implementation linked), then that’s 2^50 possible outputs. If 32 passwords are being generated per browser refresh, then that’s ~0.000000000003% of the full key space.

                                                                          Go ahead and refresh until you find something you like. You would have to refresh your browser ~17 trillion times before you reduced the keyspace by 1 bit, or 50%.

                                                                          1. 1

                                                                            Are you sure that math is right? I think you have to take into account that the user isn’t rejecting just those 31 phrases. They are using a rule to reject a huge portion of the search space. For example if you use an over-simplified rejection rule such as the user always picking the lexicographical first password out of the 32 choices the distribution is heavily skewed so guessing the password probably takes a fraction of the time on average.

                                                                            1. 1

                                                                              We probably need to clarify what we’re discussing, so there isn’t miscommunication or confusion. First, let me back up my math, then I’ll see if I understand your concern.

                                                                              The password generator generates 3-letter prefixes based on a random number of 0 through 1023, which provides each prefix with 10 bits security. It then uses those prefixes to pick words from a word list, and builds a mnemonic based on a massively large bigram DB.

                                                                              If five prefixes are generated uniformly at random, then the resulting password indeed has 50 bits security. The web interface allows you to change how many prefixes you want, resulting in the same number of words for your mnemonic. At every refresh, 32 passwords are generated.

                                                                              So, that’s 32 prefixes out of 2^50 possible = 32/1,125,899,906,842,624 = 0.000000000000028421709430404007434844970703125. 2^49 is half the size of 2^50. 2^49 possible prefixes = 562,949,953,421,312. If your browser is generating 32 prefixes per refresh, then you need to refresh your browser 562,949,953,421,312/32 = 17592186044416 times, or about 17.5 trillion times.

                                                                              At that point, odds switch to your favor that you will generate a duplicate prefix that has already been seen.

                                                                              They are using a rule to reject a huge portion of the search space. For example if you use an over-simplified rejection rule such as the user always picking the lexicographical first password out of the 32 choices the distribution is heavily skewed so guessing the password probably takes a fraction of the time on average.

                                                                              If I understand this correctly, you’re assuming the user would mentally pick a fixed point prefix such as “The first prefix must be see”. If so, then yes they lost a full 10 bits of security. However, they’ll have an 1-in-1024 chance that see is the first prefix, which is on average, 1,024 browser refreshes before they find it. If they make two fixed point prefixes, such as the first being see and the second being abs, then they have a 1-on-1024^2 or 1-in-1048576 chance of finding it. So, an average, 1 million browser refreshes.

                                                                              So while they have reduced their security margin greatly, they also increased their work load greatly, and I’m not seeing how that would be worth it. Of course, they could automate it with a script outside of the browser. Finding one prefix in 1,024 isn’t hard, nor is one in a million. Going beyond that might force them to wait it out though.

                                                                              Is this what your talking about?

                                                                              Edit: spelling/grammar

                                                                        1. 2

                                                                          I honestly don’t like the floating tab redesign. It looks and behaves more like a “button” to me than a “tab”. Now I feel like Mozilla broke the tabbed paradigm. Maybe that’s okay. Why do browsers have to have “tabs” and why not “buttons”? I’m not jiving with it though.

                                                                          1. 5

                                                                            I’ll be keeping an eye on the users, channels, and reporting server stats to see how things change over the upcoming months and years:

                                                                            Also the “top 10” at https://netsplit.de/networks/top10.php as well.

                                                                            1. 1

                                                                              Another site tracking Freenode vs. Libera.Chat servers, channels, and users:

                                                                              https://isfreenodedeadyet.com/

                                                                            1. 22

                                                                              HardenedBSD’s channel was taken over by Freenode last night: https://twitter.com/HardenedBSD/status/1397516575561879557

                                                                              What a wonderful thing to wake up to.

                                                                              1. 3

                                                                                Sorry Shawn. That sucks.

                                                                              1. 1

                                                                                Just curious, but why?