full text of post:

> After over a year of evaluation, NIST has selected 14 candidates for the second round of the Additional Digital Signatures for the NIST PQC Standardization Process. The advancing digital signature algorithms are: > > * CROSS > * FAEST > * HAWK > * LESS > * MAYO > * Mirath (merger of MIRA/MiRitH) > * MQOM > * PERK > * QR-UOV > * RYDE > * SDitH > * SNOVA > * SQIsign > * UOV > > NIST Internal Report (IR) 8528 describes the evaluation criteria and selection process. Questions may be directed to pqc-comments@nist.gov. NIST thanks all of the candidate submission teams for their efforts in this standardization process as well as the cryptographic community at large, which helped analyze the signature schemes. > > Moving forward, the second-round candidates have the option of submitting updated specifications and implementations (i.e., “tweaks”). NIST will provide more details to the submission teams in a separate message. This second phase of evaluation and review is estimated to last 12-18 months. > >NIST is tentatively planning to hold a 6th NIST PQC Standardization Conference from September 24-26, 2025, in person at NIST in Gaithersburg, Maryland.

via https://cr.yp.to/talks.html#2022.11.10

In this six minute video, Robert Miles explains public/private key cryptography in layman's terms. As a non-expert in this field, I find Miles' explanation very accessible, and I've come back to this video to brush up on this concept several times since the first time I watched it. Enjoy!

https://github.com/positive-intentions/chat

Is this a secure messaging app? probably not... but id like to share some details about how my app works so you can tell me what im missing. id like to have wording in my app to say something like "most secure chat app in the world"... i probably cant do that because it doesnt qualify... but i want to understand why?

im not an expert on cyber security or cryptography. im sure there are many gaps in my knowlege in this domain.

using javascript, i created a chat app. it is using peerjs-server to create an encrypted webrtc connection. this is then used to exchange additional encryption keys from cryptography functions built into browsers to add a redundent layer of encryption. the key exchange is done like diffie-helman over webrtc (which can be considered secure when exchanged over public channels). the algorithms are fairly easy to use and interchangable as described here.

• i sometimes recieve feedback like "javascript is inherently insecure". i disagree with this and have opened sourced my cryptography module. its basically a thin wrapper around vanilla crypto functions of a browser. a prev post on the matter.
• another concern for my kind of app (PWA) is that the developer may introduce malicious code. this is an important point for which i open sourced the project and give instructions for selfhosting. selhosting this app has some unique features. unlike many other selfhosted projects, this app can be hosted on github-pages for free (instructions are provided in the readme). im also working on introducing a way that users can selfhost federated modules. a prev post on the matter.
• to prevent things like browser extensions, the app uses strict CSP headers to prevent unauthorised code from running. selfhosting users should take note of this when setting up their own instance.
• i received feedback the Signal/Simplex protocol is great, etc. id like to compare that opinion to the observation in how my todo app demo works. (the work is all experimental work-in-progress and far from finished). the demo shows a simple functionality for a basic decentralized todo list. this should already be reasonably secure. i could add handlers for exchanging keys diffie-helman style. which at this point is relatively trivial to implement. I think it's simplicity could be a security feature.
• the key detail that makes this approach unique, is because as a webapp, unlike other solutions, users have a choice of using any device/os/browser.

i think if i stick to the principle of avoiding using any kind of "required" service provider (myself included) and allowing the frontend and the backend to be hosted independently, im on track for creating a chat system with the "fewest moving parts". im hope you will agree this is true p2p and i hope i can use this as a step towards true privacy and security. security might be further improved by using a trusted VPN.

i created a threat-model for the app in hopes that i could get a pro-bono security assessment, but understandable the project is too complicated for pro-bono work. i contacted "Trail of bits" because of their work on SimpleX and they have quoted me $50,000. the best i can offer is "open-source and communicating on reddit". (note: i asked them if i can share those details... summarized response: the SOW is confidential, but i can share the quote.)

while there are several similar apps out there like mine. i think mine is distinctly a different approach. so its hard to find best practices for the functionalities i want to achieve. in particular security practices to use when using p2p technology.

(note: this app is an unstable, experiment, proof of concept and not ready to replace any other app or service. It's far from finished and provided for testing and demo purposes only.)

• Github: positive-intentions/chat
• More information about the app: positive-intentions.com
• Follow the subreddit: r/positive\_intentions

This is a technical but quite informative article, nominally about which elliptic curves have good security properties, but also discusses the intentions behind using EC instead of older systems like RSA (basically, EC is safer against some known classes of attacks).

Posting partly because EC vs RSA came up here a few days ago.

cross-posted from: https://lemmy.world/post/18617290

> The National Institute of Standards and Technology has finally published the world’s first three official post-quantum cryptographic algorithms, tools designed to protect key systems against future quantum computers powerful enough to crack any code generated by a modern computer.

https://github.com/umutcamliyurt/TimeLockCrypt

cross-posted from: https://sopuli.xyz/post/14485657

> In case of paywall: https://archive.is/kZAgI

in my messaging app, javascript cryptography is the backbone of security so its important for it to be reliable. i would like to introduce you to my decentralized chat app:

https://github.com/positive-intentions/chat

i created thin wrapper around browser-based cryptography functions provided by the browser. it is using webpack 5 module federation to import it at runtime.

https://github.com/positive-intentions/cryptography/blob/staging/src/stories/components/Cryptography.tsx

with this i think i can effectively create encrypted p2p, which i hope to be a step towards true security (but it will take a while to get there).

(note: my app is an experimental unstable proof-of-concept. it is provided for demo and testing purposes.)

So, I've had a bit of a stupid idea for my next programming project, which would be implementing a Microsoft Recall alternative for Linux where the data is encrypted. I've now written a bit of code and have come to the point where I'd need to encrypt the files. My plan was to use asymmetric encryption where the secret key is again encrypted using something like AES and the user needs to decrypt the private key to view the screenshots taken / data extracted from the screenshots.

I have now learned that asymmetric encryption is very slow and it's generally not designed to encrypt large chunks of data, so I'm not sure how to continue. Do you think asymmetric encryption is feasible for this? Any idea how else to do the encryption? Ideally I would like for the server that takes the screenshots to not have a key that can decrypt the files since that wouldn't be as secure.

writeup from the researcher who discovered this: https://www.openwall.com/lists/oss-security/2024/04/15/6

Hatching Secret Sauce Eggs is a Rooster's Business

This is how I make the secret sauce. The recipe is inside the egg.

@cryptography@lemmy.ml