Hacker Newsnew | past | comments | ask | show | jobs | submit | kro's commentslogin

Not advocating for cashless only, but cash also has costs: banks charge for deposits and coinrolls, and you need to protect against robbery

That, + logistics and logistics security in general. I agree, the costs are real; in general, anything physical with mass = costs. So the cost savings are real too - my point is that those are instantly eaten by inflation, so going from cash to cashless and then back to cash isn't a no-op; rather, the first leg quickly turns into a no-op, then the second leg would be increasing costs.

Almost certainly it does, as public key auth takes place after setting up the session encryption

I have a setup with separated dns and domain since 2021. Using a CSK with unlimited lifetime, I never had to rotate. And could easily also migrate both parts (having a copy of the key material)

Register only has public material

The master is bind9, and any semi-trusted provider can be used as slave/redundency/cdn getting zonetransfers including the RRsigs


> Using a CSK with unlimited lifetime

Well in cases where I have had to deal with DNSSEC, I've had to rotate the KSK annually for compliance reasons.


TPM is good when combined with secureboot and these hashes being part of the attestation, that eliminates initramfs swapping. Still with Physical access being a factor bustapping can happen, ftpm - if available - is much harder to crack then than a discrete module.

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


TPM definitely rises the effort by a lot to break it. But by default the communication with it is not encrypted, so especially for modules not built into the cpu wire/bus-tapping is a thing.

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


Just use fTPM?


Good FAQ, clearly stating the weak point of physical access. For a server that threatmodel can work, for a fleet of edge/iot devices in unsecured locations without permanent uptime there is no real solution to be expected without custom silicon logic (like in smartcards) on the soc.


In general I'm all for free and European systems, but SEPA payments imo still have pain points:

- you can send money to companies and individuals alike. It's easier to trick people into fake shop payments, a card payment provider requires at least a bit it verification/registration

- it's really hard to dispute/call back sepa payments. The card companies often step in there afaik


The name of the recipient is displayed, and since last October it is also verified against the owner of the receiving bank account. The bank explicitly warns you if they differ. Also, you can't open a bank account anonymously, there is KYC.

You can't dispute or call back SEPA INST payments. But you can't dispute cash payments either. This is just fine for most day-to-day transactions, I don't need insurance when I buy groceries or pay the taxi driver.


This. Even online, most transactions I do are with known reputable businesses subject to strict consumer protection laws. I have never in my life had to do a credit card chargeback.


The title is vague, my first thought was "We already have MLKEM". Which is enough against passive attackers.

The article apparently is about the CA/certs for authenticating the server, a part of HTTPS



+1, Even if they validate DKIM/SPF+alignment (aka DMARC) that would only verify the domain. There is no local part verification possible for the receiver, the sending server needs to be trusted with proper auth


Agree, Google made it really easy here, compared to using service account certificates like with some of their other APIs.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: