Since OpenSSH is open-source, would it be helpful for Meteor to use OpenSSH cryptography in the Accounts package?
it’s looks a good thing, but i would like to see it as a pkg before to integrate inside meteor
But what will Meteor do with that post-quantum cryptography? to hash password?
Great question! Here’s a relevant quote from the article:
The entire privacy of an SSH connection depends on cryptographic key agreement. If an attacker can break the key agreement then they are able to decrypt and view the entire session. The attacker need not perform this attack in real time; they may collect encrypted SSH sessions now and then decrypt them later once they have access to a quantum computer. This is referred to as a “store now, decrypt later” attack (also as “harvest now, decrypt later”).
Fortunately, improved “post-quantum” cryptographic algorithms have been devised that rely on different underlying mathematical problems that are understood to not be attackable by a quantum computer.
OpenSSH has supported post-quantum key agreement to prevent “store now, decrypt later” attacks for several years and it has been the default since OpenSSH-9.0, released in 2022.
I understand that part but what will MeteorJS do? It uses another layer which is https and web socket to secure data transfer. Do you want to create an other layer to encrypt and decrypt data in ddp?
You know way more about this than I do. I defer to you.
100% yes, this will eventually be needed in the accounts infrastructure. Consider NodeOnFHIR to be fully on board, and willing to test the package. (ps. I’ve trained up on quantum computing while working at MITRE, and the Cybersecurity Center of Excellence; and am happy to help strategize).
We’re also going to need to upgrade HTTPS, JWT, and PKI certificate libraries. It’s my personal next 5yr refactor challenge, I think.
The latest Node v24.7.0 has incorporated this.
Splendid news. This could feasibly be rolled out in the next year. Basic road map for NodeOnFHIR looks like the following:
- Upgrade Meteor to use Node 24.7.0
- Create abstraction layer over jsonwebtoken to support ML-DSA and ML-KEM algorithm identifiers.
- The JOSE working group will need to standardize the algorithm identifier labels.
- Implement key management utilities
- Implement basic back-end services key exchange using JWT/JWK (RFC 7523).
- Establish post-quantum JWK key exchanges on back-end services (RFC 7523), using Basic Auth.
- Establish post-quantum JWK key exchanges on back-end services (RFC 7523), using Bearer tokens.
- Upgrade @accounts package to use post-quantum algorithms
- Modify express middleware and other middlewares as needed