Da più di un anno sto sviluppando un sistema di messaggistica end-to-end con crittografia (Olm/Megolm).

La scelta iniziale è stata piuttosto radicale: niente numero di telefono, niente email e nessuna identità personale richiesta per creare un account.

L'utente inizia con un nome utente e una password. Le conversazioni sono avviate tramite inviti.

Tuttavia, questa scelta non si è limitata al livello del prodotto. Ha finito per influenzare gran parte dell'architettura.

Il sistema utilizza Olm/Megolm per il livello crittografico, React sul lato client e un backend basato su FastAPI, PostgreSQL e WebSocket.

Ma la parte che mi ha coinvolto di più non è stata la scelta delle tecnologie.

È stata la comprensione di come farle funzionare insieme quando entrano in gioco identità, dispositivi, sessioni crittografiche, stato, sincronizzazione, persistenza, riconnessioni e recupero.

Un account può cambiare dispositivo.

Un browser può perdere completamente il suo stato locale.

Una sessione potrebbe non essere più disponibile quando serve.

La connessione può essere interrotta in mezzo a una transizione.

Il sistema deve continuare a sincronizzare ciò che deve essere sincronizzato senza che il backend diventi un'autorità sui contenuti delle conversazioni.

Ed è proprio qui che il modello di fiducia smette di essere una proprietà dichiarata e diventa una serie di decisioni di implementazione.

Il backup delle chiavi segue la stessa logica.

L'utente può creare una frase segreta personale che protegge il materiale crittografico necessario per recuperare le sue conversazioni.

Se accede da un nuovo dispositivo o perde i dati locali del browser, la frase segreta permette di recuperare quel materiale.

Tuttavia, la frase segreta non può essere recuperata dal servizio.

Se viene persa e non esiste un altro meccanismo di recupero valido, il sistema non può semplicemente fornire le vecchie chiavi dal backend.

Questa è una conseguenza intenzionale del modello, non una limitazione che voglio nascondere.

Durante lo sviluppo, ho dovuto modificare diverse parti dell'architettura più volte.

Non perché il sistema non funzionasse, ma perché una soluzione che sembrava corretta a un livello ha introdotto conseguenze indesiderate a un altro.

Probabilmente questa è la parte più interessante dell'intero progetto: le difficoltà sono emerse dalle interazioni tra i componenti, non dai componenti stessi.

Il sistema include anche un'architettura progettata per l'uso aziendale.

Non si tratta semplicemente di aggiungere un pannello di amministrazione alla versione per utenti finali. Il modello di business introduce requisiti e vincoli diversi e ha richiesto un'architettura dedicata.

Il codice che ho scritto finora include il backend, il client, il layer crittografico, gestione delle sessioni e dei dispositivi, persistenza, sincronizzazione e tutto ciò che serve per far funzionare il sistema come un'applicazione reale.

Ci sono già test sia per il backend che per il frontend, compresi i test del flusso crittografico che utilizzano Olm/WASM reale, verificando effettivamente la crittografia e la decrittografia tra sessioni.

Sto ora completando il frontend.

La rilascio è prevista per metà ottobre 2026.

A quel punto pubblicherò un nuovo post con un link alla versione utilizzabile e al repository GitHub, in modo che il sistema possa essere testato e l'implementazione analizzata direttamente.

Nel frattempo, sto già cercando persone che abbiano lavorato direttamente con E2EE, sistemi Ratchet, gestione delle chiavi, messaggistica multi-dispositivo, sincronizzazione e sistemi distribuiti.

Sono soprattutto interessato a capire dove le mie assunzioni potrebbero essere sbagliate.

Se hai esperienza con questi sistemi, sarei interessato a ricevere feedback sulla gestione dei dispositivi, il ciclo di vita delle chiavi e delle sessioni, recupero, sincronizzazione, metadati e modalità di fallimento.

Qualsiasi feedback, incluso il feedback critico, sarebbe utile.

Grazie in anticipo a chiunque sia disposto a prendersi il tempo per leggere questo e condividere la propria esperienza. La prospettiva di persone che hanno già affrontato problemi simili può essere estremamente utile per identificare casi che potrei non aver considerato.

Всем привет


Я написал CertGuard — консольную утилиту для Windows (на C#/.NET), которая шифрует файлы, используя гибридную схему:

- AES-256-GCM для шифрования данных
- Argon2id для деривации ключа из пароля
- X.509 сертификат для аутентификации получателя

Идея в том, что даже если зашифрованный файл перехватят, без валидного сертификата и пароля его не расшифровать.

**Ключевые особенности:**
- Работает полностью офлайн
- Не требует установки сертификатов в системное хранилище (используется файл сертификата)
- Встроенная проверка целостности

Репозиторий: https://github.com/0x80070005-windows/CertGuard

Буду признателен за конструктивную критику по архитектуре и криптографическим решениям. Особенно интересует мнение по выбору параметров Argon2id и обработке ошибок.

Спасибо.я написал CertGuard — консольную утилиту для Windows (на C#/.NET), которая шифрует файлы, используя гибридную схему:

- AES-256-GCM для шифрования данных
- Argon2id для деривации ключа из пароля
- X.509 сертификат для аутентификации получателя

Идея в том, что даже если зашифрованный файл перехватят, без валидного сертификата и пароля его не расшифровать.

**Ключевые особенности:**
- Работает полностью офлайн
- Не требует установки сертификатов в системное хранилище (используется файл сертификата)
- Встроенная проверка целостности

Репозиторий: https://github.com/0x80070005-windows/CertGuard

Буду признателен за конструктивную критику по архитектуре и криптографическим решениям. Особенно интересует мнение по выбору параметров Argon2id и обработке ошибок.

Спасибо.

I've been working on a secure messaging/networking project for a while now and I got pretty deep. Started to develop into a little test app. I'm mostly posting this because I'm curious how people who know this area better than I do would attack the model, especially people familiar with Signal, SimpleX, Berty, Tor, etc.

Sorry in advance for the ramble lol...

So say Bob and Sally are already contacts.

Bob originally connects with Sally on his laptop, then later Bob links his phone to the same identity. The phone has its own Device ID, its own key, session state etc. I'm not copying the laptop's private key over to it and I'm also not copying the existing encrypted session/ratchet with Sally over to it. But then I started thinking about what actually happens if Bob shuts his laptop off. Like completely.

Bob's phone is sitting there and Sally already knows Bob, but Sally originally established that relationship with the laptop. So how does the phone walk up and basically say something like, "Hey, I'm also Bob" without either copying some really important secret off the laptop, or having some central service sitting there with a master list of Bob's devices?

That's what I'm trying to work out. What I have working now is basically separating two points of "I'm allowed to knock on this relationship" and "I'm an authorized device in this relationship."

So Bob's phone can have enough relationship-specific information to find and approach Sally's side, but that information doesn't make the phone trusted by itself.

The phone still has to prove that the exact Device ID and exact key were actually authorized under Bob's identity, and then prove possession of its own private key. After that Sally can establish a completely separate session with the phone. Nothing gets copied from the laptop's session, and Sally also doesn't need to be handed Bob's entire device inventory just because another Bob device is trying to connect. I got this actually working now with my Mac, an Android, and another Mac acting as the other contact. I can link the Android, shut the Primary Mac down completely, and the Android can establish itself with the contact and continue messaging. Other contacts can also initiate a new message directly to the Android while Primary is still offline, then I can turn Primary back on later and it catches up with the same conversation and the same logical events instead of creating some duplicate version of everything.

And that aactually led me into another thing I hadn't really thought about when I started this lol, which is... what Primary even really means. Because if Bob only owns one device, what is it Primary of? So right now a single device is just a standalone identity. There is no Primary. If Bob links a second device, the device that authorizes that first link becomes the Primary (which can be transferred to another linked device and vice versa). But I'm treating Primary as an administration thing, not a messaging thing. It matters for stuff like adding or removing devices. It isn't supposed to be a server and it isn't supposed to be the center of the identity. Messages don't route through it, the other devices don't need it online to talk, and contacts don't need it online to talk to one of Bob's other authorized devices either.

And then when I finally got that behaving correctly, I ran into another problem. What happens if Bob's laptop and phone stop being one identity later? Because while they're linked they're obviously synchronizing things. Bob adds Sally on the laptop, the phone gets Sally. Messages go back and forth.But if Bob removes the phone later, I don't think the correct answer is that the phone now gets to keep Sally as an active contact forever just because it once received a synchronized copy of that relationship. That started feeling really wrong to me, because synchronization and ownership are not actually the same thing. So the relationship now records which Device ID actually originated it from the authenticated contact "ceremony."

If Bob's laptop originally established the contact with Sally, then while the laptop and phone are linked they can both participate in that relationship, but if they split later the active relationship stays with the side containing the device that actually originated it. The other device can obviously still have bytes on disk. I can't remotely erase something that has already been copied to somebody else's physical hardware and I'm definitely not claiming that. I'm talking about which side still has the authority to treat that relationship as active after they aren't one identity anymore.

That also uncovered another thing! lol. Originally when I linked a standalone phone into an existing identity, the phone's old identity basically disappeared underneath the new one, and I didn't really like that either. So now before a standalone device joins another identity, its old standalone identity gets preserved locally in protected inactive storage. If that phone is legitimately removed later, it can go back to being what it was before the link instead of turning into some weird revoked leftover or having to generate an entirely unrelated identity from scratch. I've been physically testing that whole process now and it's working. I can link the devices, sync them, revoke/remove one, they separate cleanly, the removed device returns to its standalone identity, and contacts/conversations stay active on the side that actually originated them. Then I can link the devices again afterward.

The contact side also learns about the removal if it's reachable, which was another piece I wanted because otherwise revocation only exists inside Bob's own devices and Sally could potentially be sitting there with stale information forever. So if Sally already has a secure relationship with Bob and Bob removes the phone, Sally can receive an authenticated revocation through an already established encrypted relationship, update the identity state she knows about, stop accepting that removed Device ID, and rotate the relationship ingress information. So the old phone doesn't just get to keep showing up with stale relationship bootstrap information and pretend nothing happened. Obviously if Sally is offline she can't learn something that hasn't reached her yet, so I'm not claiming instant magical global revocation either.

There's still A LOT to sort through, but these initial successull tests between devices has been exciting. This is bounded local-network testing right now. I'm not claiming I've solved Internet routing, NAT traversal, a perfect production crypto suite, or revocation across devices at long distances etc. The delayed routing/store-carry-forward side is also still a much harder research problem and I'm not pretending I've solved that either.

The part I'm interested in right now is more the separation between all these things. Bob's identity isn't Bob's laptop. Bob's laptop and phone don't share one private device key. Being able to find Sally's relationship doesn't mean you're authorized to participate in it. Being authorized as one of Bob's devices doesn't mean you inherit another device's encryption session. Synchronizing a relationship onto another device doesn't necessarily mean that device owns that relationship forever if the identity later splits. And underneath that, whatever route carries the encrypted data should basically be disposable. LAN, Internet, relay, Bluetooth, whatever. The route shouldn't get a vote in who Bob is.

That's kind of where I'm at. Multi-device makes sense to me while everything stays linked forever. It gets a lot less obvious once you say "okay, now take these two devices that have been sharing one identity, syncing the same contacts and seeing the same conversations, and turn them back into two completely separate identities." Who actually gets what?

Hi all! I wanted to share the result of a few months of work with all of you.

As many of you may know, inference under FHE has been a very hyped topic as of recently. The use case is clear: a medical institution or a law firm can't (or at least shouldn't) send private data to third-party AI companies for processing just to automate something simple, like sorting documents or, say, medical imaging. TEEs exist, but using them still means trusting *someone* (whoever coded up the TEE, at least). FHE is mathematical proof that your data can't be read. But since it's extremely slow, it seems to be forever destined to remain a premium product for those who need that extra bit of security (unless FHE-specific hardware comes about and becomes fairly cheap)

So i started wondering: can we make it fast? More importantly, can we make it run a full autoregressive generation chain under encryption? (this is important, because all of the published papers only price a single step of generation and do not report a full chain, and a chain is the hard case, since transformers have KV caches that grow from context & the error of one step becomes the input of the next)
And that is what i worked on. Basically, I made a 404M-param model complete 148 consecutive generation steps (server-keyed) for 64 concurrent conversations, and ran an end-to-end client keyed session of 18 generation steps. The model was trained from scratch as it itself had to be adapted for FHE. That was done by training a state-space-model instead of a transformer and swapping out every nonlinear function for a low-degree polynomial. Both of those runs were 128 bit security (HEStd_128_classic) at ring 2^17. Since ring 2^17 produces 2^16 real slots, and the model width was 2^10, I could fit 2^6 = 64 concurrent conversations in a single session. A single reading/generating step came out to be about 180s, for 64 convos that's a throughput of 2.7-2.9 seconds per token*conversation, the highest throughput for inference under FHE.. ever. The comparison is not 100% fair, of course, since my model is about 20x smaller {i couldn't afford training a 8B model from scratch, sorry lol}, per-parameter their systems are actually faster, but then again: their numbers don't measure a true generation chain. I'm leaving out some details, like the effect on model quality and scaling, since this isn't an ML subreddit, but if you're interested -- you can find them in the article.

Even more importantly, my system solves the KV-cache issue. This model's size in memory does not grow from context length: its' entire state is just 2 vectors per block and 48 for all of it. The 148-step run has proven constant memory, and nothing that I have suggests that my system can't be run indefinitely. The run showed 99.7% fidelity against the model's plaintext version, and every flip is a near-tie. There are some open questions like why the logit error grows roughly step^0.24 & whether that will saturate during a longer run or keep growing forever (note: it would take years of continious generation to go below 98% fidelity at the current rate of step^0.24)

This does not change the industry overnight and is more of an engineering result (which can probably be made into a sorta-useful product with limited use cases if you throw a fair bit of cash at it to scale/improve it further). Inference under FHE is still expensive, that didn't change.

So what about the asterisk in the title? Another project, FHE Mamba published on 2026-09-22 actually does report a generation chain of 4 steps on a single lane on an existing model (mamba), but does not report a full-security run or fidelity.

I published the project (MIT) on github: https://github.com/xelananv/fhe-ssm
as well as a more detailed article with a video: https://xelananv.github.io/fhe-ssm/#limits (ai generated so help me god)

Anyway, I'd love to hear your thoughts on this. Does AI under FHE have a future?
If anyone wants to reach out and critique my work, im down.
best of luck yall

This is a weird problem I came across when writing a NAS for my home network, bare with me here. To give some context: I fetch "dirty" data from another VLAN and store it on my "clean" VLAN, specifically my NAS. That also means that potentially attacker controlled bytes could land on my NAS itself (the chance is pretty unlikely, but still). So in order to not let that happen, I wanted to make sure the bytes that get written to my NAS are at least garbled or worthless enough for an attacker, meaning that he cannot control what bytes are exactly written out in what order. Which means I need encryption.

And here is where it gets interesting, because for my NAS-tool I also want compression. Now seemingly random bytes don't exactly compress all too well, meaning the entire effort would be nullified. So I had two choices: Either run the compression first and THEN encrypt (which makes the encryption obsolete as the compression will most likely turn the bytes into a garbled mess anyway) - or write my own mini-encryption that somewhat vaguely keeps the structure of the data while also making it impossible to tell for an attacker what bytes get written where.

Most people would choose option one and be done, but I am not most people. I don't really like the idea that attacker controlled bytes just stream directly into the complex machinery that is zlib. There have been CVEs in the past where attacker controlled bytes could actually cause OOB writes in deflation. They are extremely rare and extremely unlikely, but these bugs do exist. So I opted for the second option - also because it is more fun.

Now, most of this is to satisfy my curiosity, so don't get too worked up about it not being a billion trillion percent secure and up to FIPS standards. I run a home lab behind like 8 different security mechanisms like a VLAN, honey pot and an extremely minimal and thoroughly fuzzed JSON parser written in Haskell, so relax a little. Confidentiality is not a primary concern for me here either since if the attacker actually gets access to my NAS I am f'ed either way - and for a cloud-backup I'd use AES. This is strictly private home-network.

After this long-winded intro, I can finally get to my idea I implemented. Effectively, I wrote a small block transposition cipher. My thinking was: I need to change the bytes in a uniform way as much as possible, but keep the structure. So in the first stage I went with a random byte and just XOR'd the entire block. This would change the shape of the bytes but not the actual shape of the data itself. The issue is that there's only really 254 possible ways to change the input (excluding 0x00 and 0xFF). An attacker can easily just write out the same malware 254 times with different XORs so I'd be back to square one.

So I thought about adding two more stages. Basically I interpret a 256 byte block as a 16x16 grid. Then I first shift each column down by a random amount, followed by shifting the 16 rows each by a different random amount. The idea is that yes, I will give up some structure in the data by scrambling the data like this - gotta crack a few eggs if you scramble. But if I have large blocks of data that are somewhat similar I still do not meaningfully impact its compressibility. Blocks are being scrambled independently of each other and with the same key and shifts for each block (again, confidentiality is not a concern). Yet an attacker would not be able to tell which byte is sitting where exactly in the final block. With the XOR and the two shifts you have 16^32 * 254 different possible combinations that you can achieve for each block, which I'd guess is secure enough for an attacker not to be able to influence meaningfully (that person mind you has basically no way to connect to the NAS apart from sending dirty data over the wire).

But after implementing all of that, I started to wonder if there's a more elegant solution to both keep compressibility of data while taking away the ability of a malicious actor to place a specific byte where he wants it to be? How would you have gone about that task? And obviously: Is the solution I came up with reasonable? Obviously I could have gone down the route of just compressing right away, but given that I don't: Is my approach at least gonna somewhat work?

Would love to hear your ideas.

I'm a family doctor, not a cryptographer, but I keep running into teenagers who are clearly sharp enough to go deep into this, and who have just never been given a reason to care. The stuff I can point them at is either too basic (a cartoon about Caesar ciphers) or it jumps straight to university maths and loses them halfway down the first page.

I'm looking for the middle. Things that respect a smart 14 to 16 year old's intelligence and actually get them hooked, ideally hands-on instead of passive reading. I already know about CryptoHack and Simon Singh's The Code Book, and picoCTF has a crypto section. But I'd rather hear what worked in practice than what looks good on paper.

Two questions:

• What would you actually put in front of a gifted teenager who could go far with this?
• For those of you who ended up doing cryptography: what was the thing that first made it click? A puzzle, a book, a person?

I'm trying to build a small shortlist to hand to a few specific kids, so real experiences beat "just Google it".

Thanks.

Hi everyone!

I was thinking of some ways to improve Enigma machine (period appropriate vs period cryptanalysis).

My idea is that the rotors now have 104 contacts, 2 sets of 26 per side, and the reflector is a programmable one using the plugboard.

So, when a key us pressed, the electric signal would travel through the rotors, then in the reflector the signal goes through a cable of the plugboard OR, if a cable is not connected, goes out from the same letter (keys may use 11, 12 or 13 cables). Then the signal goes back through the rotors from the other set of contacts, then the lamp.

Naturally, both first and second pass wires though the rotor are connected to the same letters (A1-A2 are connected to J1-J2, for example).

I know this makes the Enigma harder to build (you need the double of materials and time to make a rotor), but this would let a letter to be encrypted to itself.

So, losing the classic plugboard for this "rewirable" reflector (this is not the official rewirable one, that would still not let the same letter encryption) would improve the Enigma Machine? (Still in the case of no user errors like the ones the users made during WWII).

Thanks for answering my curiosity :)

Homomorphic encryption is a cryptographic technique that enables direct computation on encrypted data without ever decrypting it first—keeping sensitive data secure even during processing.

lightphe is a comprehensive homomorphic encryption library supporting an unmatched variety of encryption schemes:

• Multiplicatively Homomorphic: RSA, ElGamal.
• Additively Homomorphic: Paillier, Damgard-Jurik, Exponential ElGamal, Elliptic Curve ElGamal, Benaloh, Naccache-Stern, Okamoto-Uchiyama.
• Logical / Bitwise: Goldwasser-Micali (XOR), Sander-Young-Yung (AND).
• Somewhat Homomorphic: Boneh-Goh-Nissim (Unlimited Additions and Only One Multiplication)

To make these powerful cryptographic algorithms easily accessible across modern software architectures, lightphe offers full multi-language support with native implementations in:

🐍 Python: https://github.com/serengil/LightPHE
🐹 Go: https://github.com/serengil/lightphe-go
☕ Java: https://github.com/serengil/lightphe4j
🟨 TypeScript: https://github.com/serengil/lightphe-ts

hi! I am interested in learning cryptography and I want to make a research about it, can someone guide me and possibly give me ways to learn more

Yesterday I started r/postquantumdiscussion to focus on all things related to post-quantum preparation. Topics include post-quantum cryptography, quantum computer advances, post-quantum mitigations, quantum defenses, etc. I've already posted a few articles that I think anyone going there will find valuable (if you have a post-quantum project).

Hi everyone,

I’m currently doing my Master’s thesis on implementing Merkle Tree Certificates (MTCs). I chose this topic because I’d like to start my career in cryptography or cybersecurity, and I thought this would be a good opportunity to get some deeper practical experience.

But now that I’ve actually started, I’m honestly a bit scared because the topic feels very broad. There are so many concepts around certificates, PKI, Merkle trees, digital signatures, post-quantum cryptography, certificate transparency, etc., and I’m worried that my foundations aren’t strong enough.

My supervisors have been very helpful, so I’m not completely on my own. But I want to make sure I use the thesis properly and build a strong understanding rather than just getting the implementation working.

For people who have worked in cryptography, PKI, certificates, or security research, I’d really appreciate some advice:

• What foundations should I make sure I understand before going too deep into MTCs?
• How would you approach a thesis like this from the beginning?
• What would make an implementation/research project like this good technically, rather than just “it works”?
• What kinds of experiments, benchmarks, comparisons, or evaluations would make the results convincing?
• Are there particular papers, books, standards, or resources you would recommend?
• How deep into the underlying cryptography should I go for a Master's thesis?
• And realistically, can a thesis on something like MTCs be a good starting point for getting a cryptography/security job, especially if I don't have previous professional security experience?

I’m trying not to panic and remind myself that I don't need to know everything before starting. 😅 I just want to approach the thesis in a structured way and hopefully come out of it with genuinely useful knowledge and a solid project that I can show to potential employers.

Any advice from people who have been through something similar would be really appreciated!

I'm looking for independent technical review or replication of a controlled experiment concerning CVE-2008-0166 (the Debian OpenSSL predictable-RNG vulnerability) and the ECDSA signing path used by early Bitcoin.

The experiment compared two Debian OpenSSL treatments:

Vulnerable: OpenSSL 0.9.8c-4etch2

Repaired: OpenSSL 0.9.8c-4etch3

I held constant the Bitcoin v0.2.0 signing path, a fixed synthetic secp256k1 private scalar, three ordered synthetic message digests, process PID/runtime coordinates, and other preregistered conditions.

The public observable was the ordered ECDSA r sequence. No historical private keys or wallet material were involved.

Across three fresh-process repetitions per treatment, the preregistered result was:

VULNERABLE_ORDERED_R_SEQUENCE_IDENTICAL_ACROSS_RESTARTS=YES

REPAIRED_ORDERED_R_SEQUENCE_IDENTICAL_ACROSS_RESTARTS=NO

POSITIVE_CONTROL=PASS

NEGATIVE_CONTROL=PASS

EXECUTION_ACCOUNTING=PASS

TREATMENT_DIFFERENCE_ISOLATION=PASS

I then froze the vulnerable treatment's three-value public r fingerprint before performing a historical comparison.

A separately qualified comparator tested that exact fingerprint against 142,302 eligible public ECDSA signatures from Bitcoin blocks 0–100,000.

ELIGIBLE_HISTORICAL_SIGNATURES=142302

VALID_PUBLIC_OBSERVATIONS=142302

PREREGISTERED_FINGERPRINT_INTERSECTIONS=0

DATASET_INTEGRITY=PASS

COMPARISON_RULE_INTEGRITY=PASS

The historical comparison was therefore a valid negative result. I am not claiming that this identifies historically vulnerable wallets, demonstrates wallet recovery, or establishes how prevalent vulnerable OpenSSL installations were among early Bitcoin users.

I'm deliberately not changing the fingerprint or expanding parameters until something matches. The completed experimental branch stays negative.

What I'm looking for now is independent scrutiny:

Is the controlled causal interpretation justified by the treatment isolation?

Are there additional confounders that should prevent attributing the restart-conditioned behavior to the Debian RNG treatment?

Would anyone be interested in independently reproducing the controlled vulnerable/repaired experiment?

Does anyone know of preserved 2009–2011 Linux systems that could independently establish the OpenSSL environment actually used by an early Bitcoin installation?

To clarify: this is not currently a paid replication request or a job posting. I'm looking for researchers who find the question independently interesting and are willing to review, critique, or reproduce the work. I completely understand if someone isn't able to devote time to it without funding.

I have a technical dossier containing the experimental design, preregistration, treatment-difference analysis, controls, integrity hashes, results, historical comparison, and limitations. I can provide it, along with the relevant reproducibility materials, to researchers interested in examining the work.

I'm specifically looking for criticism and independent verification, not confirmation of the hypothesis.

I'm also not requesting wallet files, private keys, seed phrases, passwords, credentials, or funds.

Hello,

I am currently a student in cryptography and feel like I have exhausted almost all resources for help grappling this concept, so wanted to reach out here as a last ditch effort.

While writing security proofs, you often make "games" where you create an adversay meant to attempt to break your scheme. Things like DDH, PRG, PRF, MMD etc. as proofs of A <= B transference of hardness.

I can not grapple with knowing when, and how exactly to use these different games in proofs, and most importantly, how to recognize their usefulness when constructing an adversay and a challenger.

If anyone has resources they reccomend, or tips on getting this information inside your brain, I would love to hear it.

It's likely also due to having a not strong proofs background, so if you could explain like I am three that might help too.

hey so I am trying to make a web3 project, where one roadblock I hit was that I want users to provide a proof if their balance and other stuff when sending transaction to validators…. but I am new to cryptography and know absolutely nothing so thought to use merkles, so can any one give resources for me to learn it?

ps for those who want to learn Zkp use rareskills blog

Hey, i found this Github project today for post-quantum-cryptography and i happen to use a mac book pro 2017 with mac os 13.7. I don't understand the language though and Chat GPT mentioned it as relatively new so i wanna know if anyone has had any experience with it? How good is it and do you know any alternatives i could use that might be more common/better tested:

https://github.com/Commander99/Hybridcrypt

I tried VeraCrypt but somehow i couldn't manage to install it on my mac.

The mentioned ML-KEM-1024 seems to be quite secure though: https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.203.pdf

"About

Hybride bleeding-edge Kryptographie-Software für MAC OS 13.7 und Tails OS. Basiert auf ML-KEM-1024 × P-384 × SHA-256 · ChaCha20-Poly1305"

P-384 seems to be an elliptic curve but i have no idea what "ChaCha20-Poly1305" does.

Like I know that RSA is a specific protocol, but did DH have its own protocol before it, and is that protocol separate from the fundamental idea of public key encryption?

When people talk about DH being under threat, are they talking about a specific protocol or mathematical formalism or are they talking about the fundamental ideas of public key cryptography, as outlined in Ellis 1970 and Diffie Hellman 1976?

Are we moving into a fundamentally different era or an era that is the same but with different parts? It always confuses me

And just to be clear their ideas are solely cryptography protocols and not any ideas or abstract constructions that can be transferred so they’ll be totally irrelevant right?

Hey everyone. I've spent the last few months building an ephemeral group chat on top of OpenMLS.

It started as a React Native app, where the Rust core runs natively through Nitro Modules and I was getting ~0.8 ms message encryption on-device.

Enough people asked "can it run in a browser?" that I ported the same core to WASM, and honestly the numbers surprised me:

• 0.2–0.8 ms encrypt
• 0.2–0.7 ms decrypt
• ~3 ms group setup

So performance turned out to be the easy part. The trust model is where I keep going back and forth, and that's what I'd love this community's take on. Critique welcome, that's why I'm posting.

The setup:

- MLS (RFC 9420) via OpenMLS for group key management, so epoch-based rotation, forward secrecy, and post-compromise security come from the protocol

- Same Rust core on both platforms: native on mobile, WASM in the browser. No crypto in JS, it only orchestrates

- The server just relays ciphertext. All key material is generated and stays client-side

- Rooms are ephemeral: one link creates a group, nothing sticks around server-side after it ends

Where I'm genuinely unsure:

Authentication. No accounts means the link itself is membership: whoever has it is in. I made that trade for usability, but there's no identity binding and no out-of-band verification yet. If you were designing minimum viable verification for a link-based model, would you reach for safety numbers, short auth strings, or something else entirely?

Metadata. Content is E2EE but the relay still sees IPs, timing, and group size. I try to be explicit that this is encryption, not anonymity. Would you expect a project like this to ship relay-side mitigations by default, or is that fairly considered out of scope?

There's a live demo at vanish.ws if you want to poke at the actual behavior. But mostly I'm here to have my assumptions taken apart.

Happy to share implementation details in the comments.