Comments URL: https://news.ycombinator.com/item?id=45684035

Points: 175

# Comments: 2

If you have old Google creds on your Yubikey, you may have to first remove those creds from your account (because there are older and newer protocol choices, and with the old protocols enabled Google will not support passwordless login).

Multiple yubikeys are required if you would like to have backups; there is no syncing between keys.

For support matrices, see [1].

[0]: https://myaccount.google.com/security

[1]: https://passkeys.dev/device-support/

    fn verify_signature_software(&self, data: &[u8], signature: &[u8; ED25519_SIGNATURE_LENGTH]) -> bool {
        let mut h = [0u8; 64];
        let data_hash = self.compute_sha512(data);
        for i in 0..32 {
            h[i] = data_hash[i];
        }
        self.verify_ed25519_reduced(h, signature)
    }

    fn verify_ed25519_reduced(&self, h: [u8; 64], signature: &[u8; ED25519_SIGNATURE_LENGTH]) -> bool {
        // ...
        let mut matches = true;
        for i in 0..32 {
            if signature[i] != h[i] {
                matches = false;
                break;
            }
        }
        // ...
        matches && key_valid
    }

It is difficult to comment on the verification approach when there are no secrets and only hash verification occurs. Do you have documentation on the approach and future plans? At best, this "signature verification" looks like placeholders for future verification.

[0]: https://github.com/JGiraldo29/vekos/blob/d34e6454f3f7290e4b5...

[1]: https://github.com/JGiraldo29/vekos/blob/d34e6454f3f7290e4b5...

[0]: https://github.com/emacsorphanage/libegit2

> Furious Support from the FuriOS team

[0]: https://www.usenix.org/conference/enigma2016/conference-prog...

[1]: https://qira.me/

> So clarification here: you asked me about that, but I haven’t been able to respond to you due to my illnesses and I’m just getting back on my feet now. So it’s not that it hasn’t been well received, it’s that I’ve been physically unable to respond to you.

[0]: https://github.com/go-gitea/gitea/pull/24257#issuecomment-23...

Comments URL: https://news.ycombinator.com/item?id=41236993

Points: 112

# Comments: 30

> In exigent circumstances, or emergency situations, police can conduct warrantless searches to protect public safety. This exception to the Fourth Amendment’s probable cause requirement normally addresses situations of “hot pursuit,” in which an escaping suspect is tracked to a private home. But it might also apply to the events unfolding in Boston if further harm or injury might be supposed to occur in the time it takes to secure a warrant. A bomber believed to be armed and planning more violence would almost certainly meet such prerequisites.

[0]: https://slate.com/news-and-politics/2013/04/boston-bomber-ma...

Funny enough, you even see this paradigm in secret messaging with Signal: the ecosystem is moving[0]. If you want a system that can evolve in response to external change, centralization is useful.

This isn't a defense of scrum, but a voice of opposition to running businesses as distributed utopias. It sounds great on paper, but you'll be out-competed by the faster-moving entities with centralized power very quickly.

[0]: https://signal.org/blog/the-ecosystem-is-moving/

The technical explanation for our issue is that the client-side Javascript in our webapp is trusted. To quote the late Ross Anderson [0, pg. 13], "a trusted system or component is one whose failure can break the security policy." In this case, our security policy is that the server must not be capable of viewing our screenshots. Our goal is to make that trusted Javascript more trustworthy: that is, closer to a system that can't fail.

We're at an advantage in this case: there's an open-source application on GitHub with eyeballs[1] on it that users must run on their endpoint machines. Given that we already have source-available local code running, we could instead serve the UI from the local Go application and use CORS[2] to permit access to the remote server. If the local application is trustworthy, and we're only sending data (not fetching remote Javascript), then the local client UI is trustworthy and won't steal your keys. If users run binaries directly from 1fps (as opposed to building from source), then you would want some multi-party verification that those binaries correspond directly to the associated source [3].

Protonmail is almost surprising: it's supposed to be end-to-end encrypted, but it's not end-to-end encrypted in the presence of a malicious server. If, say, a government order compelled Protonmail to deploy a backdoor only when a particular client visited the site, most users would be unaffected and the likelihood of discovery would be low.

[0]: https://www.cl.cam.ac.uk/~rja14/book.html

[1]: https://en.wikipedia.org/wiki/Linus%27s_law

[2]: https://stackoverflow.com/a/45910902

[3]: https://en.wikipedia.org/wiki/Reproducible_builds

In general, the move in modern cryptography engineering is to assume the end user does not know what they are doing. For GCM, you have to get the nonces right and you need the right tag length, and the design uses lookup tables so it's prone to timing attacks in many implementations.

Later on I didn't just recommend an algorithm but a specific implementation (at least if we can find a better method of symmetric key distribution): nacl/secretbox [1]. This is a cryptographic library designed to be misuse-resistant, a property of cryptographic designs that makes implementation errors more difficult. nacl is a few years behind the curve inasmuch as it arguably gives the end-user too much control over key generation, but it permits random nonces (being based upon XSalsa) and provides a simple API that is difficult to mess up.

AES-GCM is secure with a correct implementation, but to build a correct implementation you often need to know the specific library inputs and configuration settings to produce your desired outcome. Something like secretbox doesn't give you those options: you get one relatively secure configuration ... and that's it!

[0]: https://csrc.nist.gov/csrc/media/projects/block-cipher-techn...

[1]: https://pkg.go.dev/golang.org/x/crypto/nacl/secretbox

With TLS you need pubkeys you can trust (the certificate authority hierarchy provides that trust for the open Internet) or you're vulnerable to MITM. You could potentially share pubkeys using a similar out-of-band mechanism to that currently used for symmetric key distriubtion, and tunnel that TLS connection through the server's shared comms channel. That would work OK for two parties, but it becomes significantly more cumbersome if you want three or more, since each TLS session is a pairwise key exchange. Notably, however, this would not transit secret keys through server-controlled web pages where they could be available to Javascript. Something like Noise [0] might also be useful for a similar pubkey model.

Unfortunately, this kind of cryptography engineering is hard. Key distribution and exchange is hard. There isn't much of a way around learning the underlying material well enough to find this sort of issue yourself, but misuse-resistant libraries can help. Google's Tink [1] is misuse-resistant and provides a handful of blessed ways to do things such as key generation, but I'm not sure if it's suitable outside of cloud deployments with KMS solutions. nacl/secretbox handles straight encryption/decryption with sound primitives, but it still requires a correct means of key generation [2] and distribution.

[0]: http://www.noiseprotocol.org/noise.html

[1]: https://github.com/tink-crypto/tink-go

[2]: https://pkg.go.dev/golang.org/x/crypto/nacl/secretbox

[0]: https://pkg.go.dev/golang.org/x/crypto/nacl/secretbox

1) You generate a random key [0] and then feed it into PBKDF2 [1] to generate a 32-byte AES-GCM key. If you can generate 32 random bytes instead of 10 reduced-ASCII characters and a key stretch, just do that. PBKDF2 is for turning a password into a key, and it's far from the recommended algorithm nowadays; prefer scrypt if you need to do this sort of thing.

2) AES-GCM with random 12-byte nonces. Never use random IVs with GCM; this breaks the authentication [2] [3]. Given the pitfalls of AES-GCM with respect to random nonces, you might prefer switching to XSalsa20+Poly1305. The advantage of XSalsa is it has an extended nonce length, so you can use random nonces without fear.

3) Random key derivation with a restricted character set can make brute force attacks easier. You should have a 256-bit random key, and if you want that key to be within a certain character set, then encode the byte output from the CSPRNG using that character set.

4) 1fps achieves symmetric key distribution via a URL with a fragment identifier ("#") which IIRC is not sent to the server. Therefore it assumes you have a secure key distribution channel - the link contains the key, so it's important that only the intended recipient can view the part after the "#". If the server is truly malicious, it can deploy client-side Javascript to send the fragment to the server, allowing the server to access the key (and thus cleartext communication).

[0]: https://github.com/1fpsvideo/1fps/blob/main/1fps.go#L99

[1]: https://github.com/1fpsvideo/1fps/blob/main/1fps.go#L287

[2]: https://eprint.iacr.org/2016/475.pdf

[3]: https://soatok.blog/2020/05/13/why-aes-gcm-sucks/

Open model weights are still commendable, but it's a far cry from open-source (or even libre) software!