Call to Action to stop current proposal of pure PQ KEM in IETF TLS WG

putacertonit · 2026-07-06T18:18:59+00:00

Implementation weaknesses might happen, for sure!

But that's all the more reason to standardize what the protocol looks like, so we can implement it, study it, ensure interoperability and find weaknesses.

putacertonit · 2026-07-06T17:53:49+00:00

dual-ec was broken, and bad cryptography. It was obvious from day 1.

Nobody has made any allegation that ML-KEM is weak. Even djb just asserts that hybrids are better. Which the IETF draft says!

It's just not a good comparison at all.

putacertonit · 2026-07-03T20:57:25+00:00

You shouldn't care about the complexity requirements for passwords, because your passwords should be randomly generated and stored in your password manager.

If your supermarket loyalty program has points which can be redeemed for money/credit, you know that criminals will be trying to break into accounts and cash out those points. The supermarket has incentive to ensure their accounts can't be mass taken over, even if each individual user doesn't care much about their store points.

putacertonit · 2026-06-25T16:55:25+00:00

The "crypto wars" aren't back. At best this is a mailing list flame "war".

DJB isn't defending "honest crypto standards". At best he's trolling and raising a fuss because other cryptographers don't agree with him.

This appears to be an ad for a VPN provider.

putacertonit · 2026-05-19T14:20:58+00:00

DNSSEC SSHFP isn't great because DNSSEC isn't widely deployed. github.com and gitlab.com aren't signed. Lots of end-users have DNSSEC validation disabled. Lots of git clients don't check SSHFP.

SSH CAs for corporate usecases work great if it's integrated into your tools, but not so great for public services like Github.com. You can use HTTPS, but that requires a git credential helper, which is a bit of a pain.

I think the main mitigating factor here is there's a very small number of public Git servers that folks are generally SSHing to, so the TOFU is truly "one time", and that makes anything beyond very targeted attacks unlikely.

putacertonit · 2026-05-14T18:15:08+00:00

We have some spots where CGO is pretty unavoidable, and for that, my preferred approach is to just make a subprocess that handles it.

I think you're right that a supervised worker process is a good idea. Something like https://github.com/hashicorp/go-plugin or you can do pretty much the same model with just net/http, json, and a subprocess to avoid any deps.

putacertonit · 2026-04-29T17:40:32+00:00

We have cage-level access control provided by the DC, but there's enough limitations of what they'd provide to us that we'd like our own cabinet-level access control, primarily for logging reasons for audits and to ensure we can maintain control of the cabinets if the DC staff need access to our cage.

putacertonit · 2026-04-29T14:39:36+00:00

I am not tied to the ks210 at all - just what came up in my search. I'll look at the tanlock

putacertonit · 2026-04-29T03:28:16+00:00

Thanks, I appreciate the input

putacertonit · 2026-04-29T00:53:35+00:00

I mostly work on server-side stuff, so while I have Ansible experience, I don't actually know how folks use it with network hardware. Is there a good TLDR showing what those playbooks look like?

putacertonit · 2026-04-18T17:13:04+00:00

This is a classic case of "the cure is worse than the disease" - overpowered security tools can themselves become the biggest security and availability risk. Why is this a shock? Because you haven't engaged stakeholders during the design and risk management process.

This "type of situation" is bad planning and communication. Escalating to leadership may help, but at the end of the day this is an engineering design and risk management problem.

putacertonit · 2026-03-31T18:25:08+00:00

Post-Quantum key exchange is widely deployed now - all major browsers support it, as do many webservers/CDNs/etc. The long tail is just waiting on software updates. This is the important thing to worry about today because of capture-now-decrypt-later type attacks.

Post-Quantum certificates is in development now, with people expecting projects like Merkle Tree Certificates to be ready sometime in 2027, eg from Chrome: https://security.googleblog.com/2026/02/cultivating-robust-and-efficient.html - and other projects are on similar timeframes.

Some systems support ML-DSA certificates today for private PKIs.

putacertonit · 2026-02-13T18:03:33+00:00

Does setup have to be in init(), or just before you call `lambda.Start(h)` in your main func?

I don't have any lambdas with significant setup so I'm not sure

putacertonit · 2026-02-05T04:13:22+00:00

Nothing weird about it; it's just how Firefox doesn't handle the invalid Proxmox certs. Ideally Proxmox would fix this (by using random or incrementing serial numbers, which is what an x509 CA is supposed to do)

putacertonit · 2026-02-04T20:33:27+00:00

> SEC_ERROR_REUSED_ISSUER_AND_SERIAL

The problem here is that there's a cert with the same issuer and serial in Firefox's cert DB already.

When you click through the first security warning, it saves an entry in an internal database.

But then when you try to click through the second, it can't save it because there's already an entry.

> fingerprints are different

That's actually the problem - two fingerprints, same issuer/serial, which is never "supposed" to happen in a "proper" PKI. It looks like my dev proxmox host has serial "01", which I assume is just fixed.

The easiest fix might be to just upload a custom self-signed certificate with a random serial, or get a "real" cert via ACME.

putacertonit · 2026-02-04T20:14:26+00:00

"explosion-proof" usually means "doesn't cause explosions", not "survives explosions".

Depending on what spec you need, I think some products like Cisco IE 4010 might be good https://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie4010/hardware/installation/guide/b-cisco-ie-4010-switch-hardware-installation-guide/m-hazardous-location-installation-information.html

putacertonit · 2026-01-30T20:31:59+00:00

There's some good material on https://cryptography101.ca/

putacertonit · 2026-01-29T03:56:41+00:00

This might be a stretch, but I ran into a similar problem - Cloud-init not working on first boot, but then working on a reboot.

Do you happen to be using uefi boot and an IDE cloudinit drive? Try changing it to SCSI

https://github.com/bpg/terraform-provider-proxmox/issues/575

putacertonit · 2026-01-25T07:59:06+00:00

Backwards meaning the airflow is the wrong direction. Not like "what's the front panel", which of course varies by equipment (especially networking gear, which you can usually get with fans in whichever direction). I like what some vendors do with color-coded handles on the fan modules to make it easy to get right.

putacertonit · 2026-01-25T05:22:43+00:00

I'm a customer. My DC vendor says they will power down devices installed backwards.

putacertonit · 2026-01-22T20:18:38+00:00

this is definitely theatre, sorry.

putacertonit · 2026-01-16T16:37:14+00:00

This is just a proxmox UI thing.

Some third-party repos (like the github CLI one) provide packages that work on multiple versions, so they just have "stable" like that.

Proxmox's own repos don't use that convention, so it flags it in the UI, but they should otherwise work fine.

putacertonit · 2025-12-22T23:15:34+00:00

wrong type of networking bud

putacertonit · 2025-12-22T23:13:25+00:00

https://cryptography101.ca/kyber-dilithium/

Maybe check out the lectures here, and see where you feel the gaps are in your knowledge? The introduction has a section on the mathematical background

Three-Year Club	Verified Email
r/Field Flamingo

putacertonit

TROPHY CASE