FiloSottile

Trade groups suggesting personal behavior changes to address systemic issues with the thing they sell are such a standard playbook that I am surprised it still works.

It lifts your public keys as much as "git clone git@github.com" does.

They are not stored long-term anywhere, FWIW.

Eh, secp256r1 is fine. These days we even have complete formulas for it. secp256k1 is also fine, but in practice only ever used in somewhat legacy blockchain applications. (Recent ones tend to use pairing-friendly curves and more esoteric constructions on top.) Curve25519 is definitely a bad choice for anything but EdDSA and ECDH (and even there it's annoying) due to the cofactor, but ristretto255 reuses most of Curve25519's code and implements a prime-order group with a similar performance profile, so that's what I would pick if I needed a prime-order group in 2023.

Still, point is that there are pretty much two applications using secp256k1, who already have pretty good implementations for themselves, and the broader Go ecosystem doesn't get much from having us spend resources on maintaining secp256k1 alongside secp256r1 (which is definitely staying because of TLS and FIPS, amongst other reasons).

> I think I have more cryptographic domain experience than some random furry-avatar security blog writer.

oof

There we go. https://go.dev/cl/460537

CheckSignatureFrom is a low-level API that can't check anything about the path (including more important constraints such as nested EKUs and Name Constraints) because it can only see the immediate parent.

The high-level certificate verification API is Verify, which does check all of the above, see https://pkg.go.dev/crypto/x509#TooManyIntermediates.

We should probably add a line to the docs, to avoid users getting confused like this, but I haven't seen misused in the wild.

(I also disagree that maxPathLen does anything about raw key abuse, since once you have the key of an intermediate you can issue leaves arbitrarily, without needing to issue another intermediate, but that's besides the point.)

<3 to both :)

Love the newsletter. https://golangweekly.com

The libraries were originally written by Adam Langley, who did a great job compared to the state of the art at the time. They have been serving us well for over 13 years.

Bernstein was never involved.

Heh. Look, no one likes FIPS 140. We don’t like it, those that need it don’t like it, sometimes I wonder if NIST likes it. But it is what it is, and the current situation is marginally better than having to fix the merge every time we touch anything.

All Go+BoringCrypto code is behind the compile time GOEXPERIMENT, and mostly in its own files or in its own blocks. It could be worse.

> If the option existed and were exactly as easy to use, then why wouldn't people pick it for projects were the curve is open for selection?

It’s a good question with a nuanced answer. First, performance. The amount of data encrypted has no effect on key exchanges like X25519 and X448. They happen once per connection/exchange/encryption/decryption and have a fixed cost. In synchronous settings like TLS that time shows up directly as first byte latency. Second, a hard to quantify ecosystem risk: what are the chances you get broken by one of the few attacks that get X25519 but not X448, versus the chances you get broken by an implementation bug in the lesser used X448 implementation?

Cryptography engineering doesn’t happen in a vacuum. When selecting primitives you have to weigh the risks you are mitigating against the cost in engineering and hardware resources, and compare them against other risks you could be mitigating with those resources. It’s very unlikely the risk gap between X25519 and X448 is where anyone should invest next.

The API can easily accommodate adding a curve to crypto/ecdh, just not doing it outside the standard library. The reason not to implement X448 is simply that ~no one uses it, and it would be a lot of maintainer time to make it safe and make it fast.

FWIW, no one uses X448 because if X25519 falls it's unlikely to be due to something that leaves us with any confidence in the similar-but-bigger Ed448 curve. It will have to be a cryptanalysis breakthrough or progress in quantum computers, both of which are more likely to break both than only one.

The original Ed448 paper is a good read for understanding the "paranoia" motivation behind the curve. https://eprint.iacr.org/2015/625.pdf

Flagged because we are seeing a lot of these on HN, and they seem to be attempts to fraudulently manipulate customer support, rather than genuine stories.

“Without adjustment for other covariates, influenza vaccination was not protective in patients either with or without hypertension. After adjusting for comorbidities, vaccination was strongly associated with a reduced risk of stroke in patients with hypertension; however, there was a non-intuitive interaction, contrasting with previous studies, such that vaccination in patients without hypertension was associated with a marginally higher risk of stroke compared with no vaccination. We observed that the non-hypertensive vaccinated population was much more likely to be female, and that the young average age of the non-hypertensive never-vaccinated stratum was associated with a small number of outcomes. A possible explanation for this finding is that the increase in stroke risk in vaccinated non-hypertensive individuals might represent vaccine-seeking behaviour due to other non-vascular risk factors for poor health outcomes, such as a history of cancer or autoimmune disease, conditions for which we could not adjust. In this situation, vaccination is acting as a latent variable, identifying these individuals at risk of stroke rather than being causative in increasing the risk of stroke. Another possibility is the misclassification of hypertension status by way of undiagnosed hypertension. We also do not have blood pressure measurement or medication data and therefore cannot classify the severity of hypertension or compliance with hypertension treatment, which might influence our findings. Alternatively, this finding might simply be due to chance.”

Note that if you separate a population by enough factors, at least one will show an effect different from the aggregate, by pure probability.

This password manager seems to use private keys, so there is no passphrase used for encryption here.

However, generally speaking, age uses scrypt for password key derivation, with a default work factor of 2^18 (1 second on modern machines). Unlike GnuPG's S2K, scrypt is both CPU and memory hard.

If using the OpenPGP applet over NFC is possible, then it's almost certainly possible to use the PIV one with age keys too!

The Andorid password-store app is working on an implementation of age in Kotlin (https://github.com/android-password-store/kage) and I think they already support passage stores. Maybe you could open a feature request for age-plugin-yubikey compatibility? If you do, feel free to tag me, and I can help make sure the formats are well specified.

Hah, I saw this just after sending a newsletter issue on my password management solution, which is based on passage [1] (a fork of password-store [2] that uses age [3]) and YubiKeys.

My age+YubiKeys Password Management Solution — https://words.filippo.io/dispatches/passage/

The main feature is some protection against post-compromise exfiltration: even if an attacker fully compromises my laptop, they can't extract the whole vault.

[1]: https://github.com/FiloSottile/passage

[2]: https://www.passwordstore.org

[3]: https://age-encryption.org

That’s about fugitives being extradited from the U.S.

Hence the mention of international relations.

Super easy, just took 10k titles/comments/points from the Angolia API, formatted them as JSON Lines like the following with jq, and fed them to the very well built and documented openai CLI.

{"prompt": "A plausible Hacker News title:", "completion": " The Feynman Lectures on Physics (1964) (280 points, 62 comments) END"}

The space at the beginning of the completion is for tokenizing, and the END token is for use as a stop token in the generations.

It's part of the bit.

There's intentionally no caching, every batch is warm from the AI oven.

HN usually drives around 10k visits, so organically it's going to be well within my Saturday night budget. If someone decides to hammer it, well, the OpenAI account has a hard limit of $20/month. It will live until it's killed I guess.

There are a few sources. There's the official API [0], the Algolia search API [1], and the BigQuery dataset which is pretty up to date [2].

I used the Algolia search API, it has extremely generous rate limits and page limits.

[0]: https://github.com/HackerNews/API [1]: https://hn.algolia.com/api [2]: https://console.cloud.google.com/bigquery?p=bigquery-public-...

Maybe domain fronting was initially disabled as an unsuccessful attempt to fix that bug, that's possible and as I said I was not involved in that decision. Still, if that's the case, there was a policy decision afterwards to leave it disabled, because disabling it did not fix the bug, as you seem to agree. (Again, not elaborating on the bug publicly without permission, but I remember it turned out to have nothing to do with the SNI.)

My point is that disabling domain fronting (or leaving it disabled after finding the bug's root cause) was a policy decision, not something necessary to mitigate the bug or prevent it from re-occurring.

As I said above, I was not involved in the deliberation, so I don't know the reason domain fronting was blocked. I clearly remember it being an explicit decision though, not a bug mitigation, and Matthew's explanation on HN makes no mention of a technical issue.

I do remember one terrifying bug that Lantern was tickling which caused responses to cross streams, and I was involved in debugging that, but it was not due to the Host/SNI mismatch. It just happened around the same time that domain fronting was blocked. (I am going to respect my confidentiality agreement here, but if you want I can share what I remember here or in private.)

It's been many years, and I am still angry and disappointed by Cloudflare's decision to block domain fronting and drop Lantern as a customer. Lantern was one of the most effective Great Firewall bypass proxies at the time, and Cloudflare was expanding in China. (I was at Cloudflare at the time, but I don't have private information on the deliberation. I strongly considered quitting over it, maybe I should have, but I was junior back then.)

The CEO even came on HN to try to frame it as an abuse mitigation, accusing Lantern of exploiting Cloudflare and arguing that they were not a customer. That was obviously false because you need to have a Cloudflare zone configured for domain fronting to work. They were a customer as much as the targeted hate websites they strenuously defend.

https://news.ycombinator.com/item?id=9234367

Companies show their color in selecting who they will stand up for.

Oh I don't think Daniel was asking why we're doing i18n. My remark was not at him, at all. I was just pre-empting a possible made up objection. He's in fact correct to wonder why punycode decoding ended up in OpenSSL, as the rest of that section explores. The point being that OpenSSL could do its job and still support i18n domains and emails without having to ever decode punycode if only the spec had made different tradeoffs.

_o/ author here! mkcert is definitely my most popular tool, and it's always a delight to see how it makes developers' lives easier and how happy they are about it <3

Something that I wonder about from time to time is how "done" is mkcert. A lot of its value is in simplicity, so I've rejected attempts to make it more of a toolkit to generate all sorts of certificates (although I see the value in being able to edit the expiration and other fields). The only thing on my TODO is splitting the trust stores out into an importable package for other tools to use. Maybe that will act as a release valve for other use cases.

In a sense, mkcert will never be done because its job is also to keep up with browser requirements for you, but that goes in waves, and not much has changed in the last couple years. (Unlike the first years of mkcert, when things were really a moving target.) Similarly, it has to keep up with new trust stores and ways to install into them, and we might be overdue for a pass of that, but these are not really new features, just maintenance.

Previously:

Mkcert: Tool for making locally-trusted development certificates — https://news.ycombinator.com/item?id=17748208 — Aug 2018 (39 comments)

Show HN: Mkcert – Valid HTTPS certificates for localhost — https://news.ycombinator.com/item?id=18842218 — Jan 2019 (118 comments)

Bingo. The support cost of MFA, especially non-SMS methods where some of the recovery process is delegated to the mobile operator, is the top-level bit.

It’s frustrating to see technical people discount or ignore that side of the deployment work, because that’s the kind of issue that actually blocks most security and cryptography measures in practice.

If I had a thousand dollars for every time I heard “just make the user keep a key safe” I could fund so much UX research :)

This is a mildly interesting observation/tool presented in the most overblown and irresponsible way.

WebAuthN is meaningfully phishing-safe. You can’t replay a login for attacker.com to example.com. What part 1 is demonstrating is that if you compromised the victim’s machine you can arbitrarily use a token for as long as it’s connected. What part 2 is demonstrating is that if you choose server-side to allow subdomains (it’s an option!) and then an attacker takes control of https://subdomain.example.com, they can replay a subdomain login against example.com.

Needless to say, your average phisher doesn’t have control over the victim’s machine or one of the target’s subdomains. It’s still interesting because you might encounter a combination of server-side misconfiguration and user controlled subdomains (like the deprecated user.github.com), but far from an indictment of WebAuthN.

Arguing that calling WebAuthN phishing-safe is a “scam” or that 100% phishable TOTP or MFA over Signal (??) is better is detached from reality and harmful. I wish InfoSec didn’t reward these antics.

The page itself mentions how it consumes less resources, and requires less permissions.

One thing is not trusting the NSA, another is being asked to dismiss the work of well-know independent academics because they engaged in an open selection process run by NIST without any objective proof of technical issues.

Again, the FOIA is good, the framing and FUD is harmful and part of a pattern that might be hard to see outside the community.

This kind of flexibility is a non-goal of crypto/tls. We have a TLS stack with one of the best security track records because we implement an opinionated subset of the specification, amongst other things. Moreover, fingerprint evasion is a cat-and-mouse game we can't sustain in the six months Go release cycle.

That doesn't mean I don't care! I was just talking with a friend about this the other day, and I suggested it should be possible to make a small, easily maintained patch that focuses on chasing the fingerprint of one well-known browser. He implemented https://github.com/hellais/utls-light in that spirit, which looks like a viable solution to me.

Anyway, I think matching TLS fingerprints to HTTP User-Agent strings is a valid abuse prevention technique. Rejecting any non-browser fingerprint is bad, and websites should get pushback for that, but I am skeptical that's something they can reliably do without breaking any time Chrome flips a field study. TLS is not _that_ rusted shut.

The standard library is very unlikely to include, or at least expose, non-final standards. I personally plan to toy with implementing Kyber soon, and plan to produce an experimental age [0] plugin. If a TLS experiment were to gain traction, I don't exclude we might support it in the standard library, since it would be negotiated and we'd be free to drop it later on.

[0]: https://words.filippo.io/dispatches/post-quantum-age/