This is undoubtedly the most promising Post-Quantum TLS deployment situation I have seen for #Tor since we started discussing it more actively in the team. Very exciting!
I hope that OpenSSL 3.5, when released, will make it into #Debian Trixie. That would make deployment of this so much more snappy and easy for the Tor network to upgrade, but that may be dreaming. The timelines here look quite difficult for that to happen, but let's hope.
Lo and behold, #OpenSSL 3.5 (their upcoming LTS release) will come out here at the beginning of April, and it does indeed support some of these hybrid PQC schemes. Their recent beta2 announcement can be read here: https://openssl-library.org/post/2025-03-25-openssl-3.5-beta/ and their roadmap is at https://openssl-library.org/roadmap/index.html
Very excited by this work. Big kudos to the OpenSSL Team here! 
Already planning on giving this a spin with the C implementation of #Tor later this week to see how it goes!
#FBI raids home of prominent computer scientist who has gone incommunicado
Mar 24, 1944: On this date, the poem The Life That I Have was issued by Special Operations Executive cryptographer Leo Marks to agent Violette Szabo. The poem was made famous by its inclusion in the 1958 movie about Szabo, Carve Her Name with Pride. (1/2)
I was just ranting about #QKD in a chat with someone, when I compared quantum-resiliant cryptography with quantum key distribution like this, and noticed that I really like this summary:
If you want to go 500 meter down the street you can either take your bike or call a helicopter to your place, have it hover over your home, climb up a rope ladder, have it fly you those 500 meters and dis-rope.Both of these get you to your destination, but one of them is faster, cheaper, less complicated, relying on more established infrastructure, scales better and is just about superior in every relevant regard. And it’s not the helicopter/QKD.
This is a wonderful explainer on zero-knowledge proof/zero-trust verification. So simple, yet so clear.
So far, I have been delving into the #Web3 and #crypto debate only superficially, as the very few notions I got led me to abhor any kind of technology related to the #blockchain.
Since I started my new job at @dweb, though, I am finding myself revisiting my position by deepening my knowledge on the topic. I am mostly drawing the same conclusions—crypto is terrible—yet I am glad I am learning more also on what I am very critical about.
I am particularly thankful to @mai for writing this article, which I believe is a great starting point to develop an informed opinion.
Above all, as mai points out, nothing is all-bad, and there are for sure ideas and practices that can be learned (as cautionary tales in the worst case scenarios) even from problematic technologies, communities, and/or founders.
Guys I've been thinking about this recently
So the telegraph has existed for a while, and became widespread in 1800s. Charles Babbage worked on the first mechanical #computers in the 1820s
What would be the earliest point in time in which a #Bitcoin like #Blockchain could've been made?
As I understand it all the system needs is a #network of computers each running a program that checks for transactions
I'm wondering if a different hash function was used it could be a lot simpler to implement into hardware, but if mechanical computing wasn't powerful enough for that the earliest might've been after WWII with the code breaking machines that the Allies invented
Any boosts would be greatly appreciated!
"US politicians and privacy campaigners are calling for the private hearing between Apple and the UK government regarding its alleged encryption-busting order to be aired in public."
https://www.theregister.com/2025/03/14/apple_uk_encryption_hearing/
"Colloquially, the IPA is referred to as the Snooper's Charter since its aims are to legally empower intelligence agencies with greater surveillance powers."
If data is the new oil, why give yours away?
Your company’s ideas, strategy, and data are its most valuable assets. Why let someone else control them?
See how CryptPad Enterprise puts power back in your hands. Join our free webinar. Registration is required: 
https://xwiki.com/en/webinars/CryptPad-Enterprise
#webinar #oss #tech #technology #Cryptography #HowTo #demo
seems my #introduction didn't migrate so here we are.
hello. i used to be on fosstodon at @jabster28@fosstodon.org, but running my own seemed fun so now i'm on my own #sharkey instance at mace.lol
i'm currently in university for a computer science degree (no i won't be homeless.). i do a lot of #programming and like to mess around with general #devops stuff (containerisation and networking mostly) in my free time, a lot of my mini projects revolve around automating this or that and making it work with everything else i have in my own ecosystem.
i #selfhost a lot of services for ephemeral file sharing and password management etc.
my main languages are #javascript / #typescript and #rust but i've been wanting to learn some #cpp or c# recently (i don't always want a program that's 1000% correct, cargo.)
(also css is genuinely an a tier language. insanely fit for purpose.)
i do some #networking and find it pretty fun mostly
i play a lot of #splatoon in my free time. i'm also fond of #mahjong, #minesweeper, and #tetris (modern tetris (usually techmino), not the official app) to sink my time into if i'm on my phone or something.
some more stuff i'm into that's probably more fringe:
#wikipedia editing is pretty fun, though it's rare that i'll get a chance to correct/add to an article that i know about and can source. doing coi requests is cool, though, you see some really interesting people
i'd love to be able to do #cooking faster but i feel that's only possible with enough time or money to cook when you don't need to (i have neither)
#libraries are really cool and i'd love to go to more of them and document them. working at one seems fun also
slightly related but i wouldn't mind getting better at #photography at some point (maybe make a pixelfed account?)
my only major political stance on here would probably be that #privacy is a fundamental human right, and a lot of things online right now don't let you control that as well as you should
i guess that leads into me liking #monero, there's not many other ways you can transfer wealth to someone without anyone else snooping. no, b*tcoin doesn't count, it's simply not fit for purpose.
that also goes into #cryptography i suppose. the mathematics inside things like ecdh is pretty beautiful. one of the reasons i'm going to university is to eventually be able to fully understand elliptic curves and a lot of the cryptography we use nowadays.
that's it, thanks for coming to my ted talk. make sure to smash that like button, subscribe, and hit the red bell to get notifications when i upload. also be sure to donate to my patreon and ko-fi, link's in the description. you can also buy the product from this video's spons-
okay i'm done
you should do a random act of kindness today. maybe tomorrow. or not, i'm not your mom.
@sebsauvage @titaniumbiscuit not all classic e-mail providers work equally well but many do. Since #chatmail entered the global e-mail server network 14 months ago, and we introduced instant-onboarding april 2024, we de-emphasize #gmail #outlook and #iCloud and don't perform "free" work to help them continue to dominate. Instead we put our energy into growing the chatmail server network which does away with spam/rate-limit problems by design. Everything is based on #interoperable #cryptography .
But cryptography is hard. Until recently, institutions and individuals who need to run #cryptographic operations had to rely on specialists to review the code that their applications is running. Cryptography can protect our privacy and authenticate sources of important information. For #cryptography to work for the people, the people need to understand it.
Last week, I finally finished my writeup of a vulnerability based on a misuse of #Cryptography that we found a while back in a penetration test. It's my favorite vulnerability so far, as it relies on abusing basic properties of unauthenticated encryption and shows, in a real-world scenario, how such seemingly theoretical issues can compromise an entire system. In the end, it's a teachable moment about both cryptography and secure software architecture.
I had the draft lying around for more than a year, but reading the articles by @soatok finally reminded me that I should really wrap this up and post it. So, here it is: https://blog.maass.xyz/encryption-isnt-enough-compromising-a-payment-processor-using-math
Since I just checked again for a lemmy post and verified that my complaints are still current:
I explicitly recommend against the use of @threemaapp@mastodon.social as a messenger because of their bad #encryption.
I make this recommendation as a professional cryptographer who holds a PhD in that field and give explicit permission to be quoted on it.
The reason for this recommendation is that Threema’s End-to-End encryption offers no forward- or backward secrecy of any kind. This follows directly from the protocol description they themselves publish in their own whitepaper, so if this is a wrong claim, their own publications are wrong, which would be just as much of a reason not to use them!
Any claims about forward-secrecy they make is purely about their transport-layer encryption, which offers zero protection against corrupted servers. If someone corrupts signal’s servers they don’t get anything. If they corrupt Threema’s servers they get everything as ciphertexts that are merely encrypted with a pairwise static key that does not get updated.
A good messenger should not rely on the trustworthiness of the servers, so doing it like that does is not acceptable and enough reason to give the boot to their app.
As much as I dislike its lack of federation (not that Threema is doing any better there), this still means that #Signal remains my recommendation as messenger, with #matrix being an alternative that feels like it makes a degree of sense to me. Other than those two we quickly get into “wouldn’t recommend” territory!
#Threema #itsec #cryptography
So looking through some old projects I’ve had lying around, I ran into something I started (and never even really wrote anything) about steganography. This led me down a bit of rabbit-hole and I now have a slightly better understanding of some components of ML-KEM (aka. #Kyber).
Both the public key and the ciphertext are for the most part long sequences of integers modulo 3329 that are effectively indistinguishable from random integers out of that range.
Of course they are obvious to distinguish from random bitstrings, but the easiest way to fix that would be to just view them as numbers in base 3329, re-encode them to base 2 and work from there… So that might be one thing I could look into now.
The alternative is to see whether there is a sufficiently hard to detect way to change some of the representatives of the field-elements… It might be easier to implement if, if not easier from a mathematical perspective, but would also let the possibility of slightly compressing the public-key and ciphertext by about 2.5% in length lie on the table.
In any case, this is something that might be worthwhile for practical use-cases… 
#cryptography #pqc #pqcrypto #steganography #crypto #MLKEM
#deltachat is a minority messenger today and that's just fine for now. Changes often come from the precarious fringe which has to make ends meet, under hostile circumstances. Our approaches are aiming to provide working software that does its damn job. No unable to decrypt, no going for VC/Blockchain money, no bending the knee and no endorsing of corporate platforms. The #chatmail server network implements #interoperable #cryptography , does away with shady spam lists, catering for #Gmail etc
I’m currently at a research-retreat with my colleagues and my group (we split into two, based on which topic we liked more) is reviewing a paper by a certain expert who designed a (by some pretty reasonable metric) more efficient scheme than some previous work.
(The following is very vague both to avoid throwing round accusations that could still end up wrong and because we might still want to work on it.)
Now there was one thing in the construction that screamed “PROOF ARTIFACT” and one of my colleagues who found this pretty off-putting eventually noticed that there seemed to be a way to just get completely rid of it.
Following from that I then noticed that the proof contained an interesting problem in that it combined two things of which you really can only use one, at least in theory. (In practice it is interestingly enough far less of an issue.)
So we now have three options:
* “Fuck it”: Just take the solution that my colleague found and point out that the protocol we improve upon already does the fishy thing.
* “Formalize it”: Design or find a design for the two primitives that solves the conflict. It’s going to be super messy either way, but it would do a better job a justifying the “Fuck it” solution.
* “Fix it”: Perform a much more fine-grained analysis on the conflicting definitions, extract only the parts that are strictly needed and see if they can be made to agree with each other.
In the end our plan is probably to do all three, which could actually result in a pretty nice paper. And if we get somewhere with the “Fix it” solution or in the event that nobody has yet done a good job at “Formalize it” (unlikely!) and we figure something out those might actually end up being pretty nice results in general.
#cryptography
