HN user
My name is Steve Weis. I live in San Francisco and am interested in security, cryptography, and privacy.
http://saweis.net
The NSA is not trying to weaken ML-KEM. The IETF TLS working group is simply trying to publish a pure ML-KEM specification. It does not impact the hybrid ietf-tls-ecdhe-mlkem specification at all.
The context of this is that D.J Bernstein has been moderated 7 times from the mailing list for repeated unprofessional and disruptive behavior: https://mailarchive.ietf.org/arch/msg/tls/lON9lKptnJ6ccq2-I1...
“ There was a bug in an OpenPGP library which finally gave us an excuse to tear encrypted email via PGP to shreds. Our special guest William Woodruff joined us to help explain the vuln and indulge our gnashing of teeth on why email was never meant to be encrypted and how other modern tools do the job much, much better.”
I dug into this once and the "theoretical ideal" of 3 originated in a 1950s paper about vacuum tube computers, which itself immediately backed off and said the choice of base 2 is frequently justified.
https://sweis.medium.com/revisiting-radix-economy-8f642d9f3c...
In this case, the context are {-1, 0, 1} weights in a LLM model, which I don't think is being used for any hardware efficiency argument. I think it's just quantizing weights into 3 states.
The video of the talk is online now too: https://www.youtube.com/watch?v=7VWNUUldBEE
The best estimate I've seen is that we need about 5-7 orders of magnitude more qubits and 1-2 orders of magnitude lower error rates: https://sam-jaques.appspot.com/quantum_landscape_2023
Rambus bought Cryptography Research about 12 years ago: https://www.rambus.com/rambus-completes-acquisition-of-crypt...
NIST P-256 curve seed came from the X9.62 specification drafted in 1997. It was provided by an NSA employee, Jerry Solinas, as an example seed among many other seeds, including those provided by Certicom. Read this for more details: https://eprint.iacr.org/2015/1018
"High q-bit proprietary technology" and "specialized de-latticing algorithms" are made up terms that nobody uses.
A post talking about how Jerry Solinas provided the NIST ECDSA curve parameters and anecdotes of how they were chosen.
NIST post-quantum standards resulted from a 8+ year process and public competition: https://csrc.nist.gov/projects/post-quantum-cryptography
The record quantum computers can factor is 21 -- and that is by cheating by already knowing the factors are 3 and 7. There are other results that use special form composites which don't count.
So a QC can factor a 5 bit number with Shor's algorithm in 2023 (with some cheating). That record has not changed for 10+ years.
I publicly bet 8 years ago that nobody would factor the number 35 by 2030. I hope I'm proved wrong.
This is appearing at Crypto'23: https://crypto.iacr.org/2023/program.php
Video of a previous lecture is here: https://www.youtube.com/watch?v=4xNk3B-4TKs
The record for factoring using a quantum computer is 21. Don't read that as 21 bits. 3*7. This has been the record for 12 years and that is arguably a result that is "cheating" with a priori knowledge of the factors.
There are some other examples of people factoring special-form composites that are particularly easy to factor on quantum computers, but those are basically stunts with no impact.
To threaten RSA, quantum computers need to increase the number qubits 6 orders of magnitude and improve the error correction at least 2 orders of magnitude. Check out this blog post for an illustration of where we are at: https://sam-jaques.appspot.com/quantum_landscape
Oded Goldreich's "Foundations of Cryptography" books are the rigorous, theoretical oriented books used in many grad-level crypto courses: https://www.wisdom.weizmann.ac.il/~oded/foc-book.html
Neil Koblitz has "A Course in Number Theory and Cryptography", which I haven't read, but is often used: https://www.amazon.com/Course-Number-Cryptography-Graduate-M...
Also, Boneh and Shoup is good and mentioned in other comments: https://toc.cryptobook.us/
You can't just base a business in a QOZ and call it a QOZB. It needs to generate 50% of its gross income from within the zone and 40% of its intangible property (e.g. software) must be used for business within a zone.
Further, there are restrictions on what kind of business it can be. It can't be, for example, a golf course or a liquor store.
I think we are many, many years away from a quantum computer being able to break 256-bit ECC:
https://sam-jaques.appspot.com/quantum_landscape
https://www.bsi.bund.de/EN/Topics/Cryptography/QuantumComput...
The current record in factoring with Shor's algorithm is 21. Yes. 3*7. That record has stood for 12 years and arguably is not even running Shor's because it required a priori knowledge of the factors.
Even with "cheating" by using knowledge of the factors, in 20 years we have seen seen a single bit of improvement.
None of the new quantum computers from IonQ, Google, or QuEra with 32-256 qubits are even able to even replicate those early results. D-Wave claims 5000 qubits, but that is for adiabatic QC, which to my knowledge, cannot run Shor's algorithm.
To be a threat, QCs need millions of qubits and orders of magnitude better error correction. I think people make the mistake of looking at the speed of progress of classical computers and thinking it applies to QC. It's just not happening.
I don't think QKD is practical, yet there are constantly companies trying to sell it. I don't really understand who is the market -- not big companies and not the US government.
The NSA recently issued guidance to government agencies that it "does not consider QKD a practical security solution for protecting national security information".
https://media.defense.gov/2021/Aug/04/2002821837/-1/-1/1/Qua...
A quantum computer is not "infinitely parallel" and though it's still an open problem, it's considered unlikely that that quantum computers can solve NP-complete problems in polynomial time.
I don't think a balanced-ternary Setun was ever built in hardware. It was emulated on a base-4 machine according to this contemporaneous RAND report by Willis Ware [1]
The Setun creator N.P. Brousentsov made a lot of dubious claims, including that Setup "worked correctly at once without even debugging" [2].
Balanced ternary was never competitive in transistors. It was hypothesized to be more efficient for vacuum-tube based ring counters, and even that was "only approximately valid, and the choice of 2 as a radix is frequently justified on more complete analysis" [3].
[1] https://www.rand.org/pubs/research_memoranda/RM2541.html
[2] https://www.computer-museum.ru/english/setun.htm
[3] http://bitsavers.trailing-edge.com/pdf/era/High_Speed_Computing_Devices_1950.pdfFor context, this site was at Mt. Zion Missionary Baptist Church in West Oakland. It was intentionally located there to target the local underserved communities. At the time, California was in phases 1A and 1B. This was intended for elderly and essential workers.
There was misinformation that it was first-come, first-serve to anyone who wanted it. I looked into it at the time and it was easy to verify that this was not true. The CA State website, the church's fliers, and their help line were all clear.
Here's an example clearly listing who was eligible: https://twitter.com/SarahBelleLin/status/1370071520953835520...
They intentionally did not check eligibility to avoid putting barriers up for high risk people. It was effectively an honor system.
This site ended up being oversubscribed and most doses went to people outside the targeted area or demographic: https://www.sfchronicle.com/local/article/A-West-Oakland-chu...
There's also a web-based relay for magic-wormhole: https://webwormhole.io/ https://github.com/saljam/webwormhole
This book is mostly minimal examples in whatever Python library the author decided to use. There are some major gaps.
For example, the section on Python libraries doesn't even mention the most commonly used Python crypto library (cryptography): https://github.com/nakov/Practical-Cryptography-for-Develope...
Similarly, the Java section essentially mentions a single, obscure library besides the JCE and Bouncy Castle: https://github.com/nakov/Practical-Cryptography-for-Develope...
There's also no mention of libsodium besides a bullet list item.
"WHO Points To Wildlife Farms In Southern China As Likely Source Of Pandemic" https://www.npr.org/sections/goatsandsoda/2021/03/15/9775278...
https://www.nytimes.com/2021/02/14/health/WHO-covid-daszak-c...
Historically, SARS-CoV-1 is suspected of being transmitted from bats to civets: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3291347/
In Feb 2020, China shut down its wildlife farming industry and sent out directions on how to kill and dispose of the animals: https://www.nature.com/articles/s41893-020-00677-0
http://www.npc.gov.cn/npc/c30834/202002/c56b129850aa42acb584...
https://multimedia.scmp.com/infographics/news/china/article/...
Wildlife farming was a $70B industry that employed around 2% of China's workforce. There was a short-lived ban in 2003 in response to SARS-CoV-1, which was later rescinded.
The original statement I had disputed was "[Facebook has] the keys to decrypt [Secret Conversations messages]", which is false.
If you think the contrary, then the evidence is in the client.
It's a falsifiable assumption. Audit the binaries if you want to convince yourself. You will see code to generate and use keys locally, with no mechanism to fetch or share keys from a server.
If you want to go beyond generic concerns, there are plenty of academic papers that have looked at Facebook Secret Conversations, found actual issues, and helped get them fixed: https://link.springer.com/article/10.1007/s00145-020-09360-1 https://link.springer.com/chapter/10.1007/978-3-319-63697-9_... https://link.springer.com/chapter/10.1007/978-3-319-96884-1_...
Your assertion is false. Please read the whitepaper.
Facebook does not have the key to decrypt messages sent with Secret Conversations. It is generated on-device. You can confirm that using simple reverse engineering tools on, say, the Android APK.
Yes, Facebook could subvert the binary by pushing an update. That is the risk you are accepting.
Also, ZuccNet is using RSA-2048-OAEP to encrypt each message: https://github.com/tomquirk/zuccnet/blob/master/src/util/cry...
This is not forward secure. It will also only work for messages under 256 bytes. I don't know what happens in this code if you exceed that message length.
You want to use ephemeral session keys here. Read the Secret Conversations whitepaper as an example.
Facebook Messenger already has Secret Conversations, which is end-to-end encrypted mode based on the Signal protocol.
Here's the technical whitepaper: https://about.fb.com/wp-content/uploads/2016/07/messenger-se...
Here's some of the academic work on messaging franking that it has driven: https://eprint.iacr.org/2017/664.pdf
Here's the instructions how to use it: https://www.facebook.com/help/messenger-app/1084673321594605
Of course, you need to trust that the client from the app store and no, the implementation is not open source.
This is brilliant unintentional parody.