Microblog entries before 2022.11.15 appeared on Twitter (@hashbreaker; see history of the name), and were archived here on 2022.11.18. Newer microblog entries are appearing on Mastodon (@djb@cr.yp.to) and on Twitter and here (with timestamps from Mastodon).
2024.04.24 22:50:49: Is your .tex file using typical Computer Modern fonts, \mathbb from amsfonts/amssymb, and boldface for definitions, section titles, etc.? Are you annoyed at \boldmath not affecting \mathbb? Solution: https://cr.yp.to/2024/20240424-bfbb/bfbb.pdf https://cr.yp.to/2024/20240424-bfbb/bfbb.py https://cr.yp.to/2024/20240424-bfbb/bfbb.tex
2024.04.22 10:36:08: My initial assessment of https://eprint.iacr.org/2024/601 is that (1) the "halved dimension" is actually what people normally call the "dimension" for NTRU; (2) Section 4 is understating what the usual attacks accomplish; (3) all 2024/601 exponents are above the usual exponents.
2024.04.22 09:35:20: Next round of interesting lattice claims to dig into: https://eprint.iacr.org/2024/601 claims to prove that "breaking NTRU lattices can be reduced to finding shortest lattice vectors in halved dimension". For comparison, Table 5 of https://ntru.org/f/ntru-20190330.pdf is around 70% of the dimension.
2024.04.20 15:40:40: Tracking down some TIMECOP alerts led to a 2021 gcc patch from ARM (https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=gcc/match.pd;h=d70720c2382e687e192a9d666e80acb41bfda856) turning (-x)>>31 into a bool, often breaking constant-time code. Can often work around with (-x)>>30, and asm is safer anyway, but for portable fallbacks we need security-aware compilers.
2024.04.17 17:47:00: For people asking how to host a discussion without inflicting @discord (and non-responsive @discord_support) on new users: I've had good experiences with @zulip (@zulip@fosstodon.org). Many active chats are on the central https://zulip.com servers; also easy to self-host.
2024.04.17 08:45:27: Maybe @discord is ok for people who have already been using it for a while, but setting up new discussions there is a terrible idea. I received an invite link, created an account, crashed into ill-conceived @discord restrictions on new accounts. No response from @discord_support.
2024.04.16 15:47:30: https://cr.yp.to/papers.html#latticeasymp has (1) an asymptotic thm; (2) proof; (3) formally verified proof. Had originally included #1+#3 in https://cr.yp.to/papers.html#lprrr. Later realized that #2 still has value: gives idea of #3; illustrates proof size that's formally verifiable in a few person-weeks.
2024.04.12 21:10:34: Reminder for the sales team: If https://eprint.iacr.org/2024/555 turns out to be wrong, relentlessly hype the failure. If it turns out to be right, relentlessly hype the exponent in the approximation factor. Always remember: any attack claim short of a full break is a win-win scenario.
2024.04.12 17:24:27: One of many papers in the first issue of the new IACR Communications in Cryptology is my survey "Understanding binary-Goppa decoding": https://cr.yp.to/papers.html#goppadecoding First 20 pages are a minicourse on the decoder used for McEliece. Appendices cover tests and formally verified proofs.
2024.04.11 20:54:27: "Referees and other readers provided with a computer-checked proof spend much less time worrying about the possibility that the theorem is wrong" (quoted from Section 1 of "Papers with computer-checked proofs", https://cr.yp.to/papers.html#pwccp, September 2023)
2024.03.24 14:36:01: Searching for ways to communicate without exposing your information to Google? Here's a PDF ("Portable Document Format"), created with standard tools, containing a red message that's invisible to (pre-123) Chrome users: https://cr.yp.to/2024/20240324/secret.pdf Joint work with Jolijn Cottaar.
2024.03.21 17:03:25: lib25519-20240321 released: https://lib25519.cr.yp.to https://lib25519-cr-yp-to.viacache.net Includes more speedups from Kaushik Nath, a simple use-s2n-bignum option, MacOS support, and more. Still generally needs formal verification and auditing, but AWS's s2n-bignum code is formally verified.
2024.03.14 06:41:16: Fun fact noted in the code: if you change first 0x30 in openssl_ed25519_lib25519.c to, say, 0x31 then the edtest script triggers double-free in the OpenSSL core when it calls openssl req. String contents corrupting pointer structures! Hopefully never attacker-influenced strings.
2024.03.14 06:25:29: Releasing beta for auditing: small-ish OpenSSL 3 "providers" to use lib25519 (gives big speedups, although still needs verification) for X25519 and Ed25519. Code: https://cr.yp.to/2024/20240314/openssl_x25519_lib25519.c https://cr.yp.to/2024/20240314/openssl_ed25519_lib25519.c Current test scripts: https://cr.yp.to/2024/20240314/xtest https://cr.yp.to/2024/20240314/edtest
2024.03.12 20:19:44: I clicked on "Google's Threat model for Post-Quantum Cryptography". 2MB page; below web average. I was hoping it would explain how Google sees Kyber-768 as such low risk as to not move up to Kyber-1024 (384 bytes larger key, 480 bytes larger ciphertext): https://bughunters.google.com/blog/5108747984306176/google-s-threat-model-for-post-quantum-cryptography
2024.02.15 18:17:54: 2009: "Not covered in this talk: other types of DoS attacks. e.g. DNSSEC advertising says zero server-CPU-time cost. How much server CPU time can we actually consume?" https://cr.yp.to/talks.html#2009.08.10 Also posed the question in some later talks. Most recent answer: https://www.athene-center.de/fileadmin/content/PDF/Technical_Report_KeyTrap.pdf
2024.02.01 00:18:36: Columbia Accident Investigation Board, final report, 2003, volume 1 (https://history2.nasa.gov/columbia/reports/CAIBreportv1.pdf), page 191: "The Board views the endemic use of PowerPoint briefing slides instead of technical papers as an illustration of the problematic methods of technical communication at NASA."
2024.01.19 21:03:54: Recent claims of exponents for supposedly well-studied lattice attacks considering memory-access costs: 2023.11, https://web.archive.org/web/20231125213807/https://finiterealities.net/kyber512/: 0.396! Oops, wait, 0.349! 2023.12, https://web.archive.org/web/20231219201240/https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/faq/Kyber-512-FAQ.pdf: 0.349, or 0.329 in 3D! 2024.01, https://web.archive.org/web/20240119081025/https://eprint.iacr.org/2024/080.pdf: 0.311, or 0.292 in 3D!
2024.01.18 23:46:16: Is there a name for the following failure pattern? (1) "Don't worry about flaws in defense X: we have Y as another layer of defense." (2) "Don't worry about flaws in Y: we also have X." (3) "This real-world attack exploited flaws in X _and_ in Y? Nobody could have expected that!"
2024.01.18 17:59:00: Puzzled by AMD manuals saying that VPMASKMOV might fault on unused addresses. Does it actually do that on any AMD chips? Intel manuals guarantee it won't, making it useful for 256-bit processing of array lengths that aren't multiples of 256 bits, but could such code crash on AMD?
2024.01.17 00:55:48: Updated sortbench (int32 arrays, AVX2) to add Intel's x86-simd-sort, add the "fast-and-robust" library, upgrade to latest version of Google's vqsort, support current vxsort, and include baseline std::sort: https://sorting.cr.yp.to/comparison.html Let me know if I've missed a competitive library.
2024.01.03 07:30:58: A recent preprint "The Planck Constant and Quantum Fourier Transformation" (https://eprint.iacr.org/2023/1971) suggests that Shor is unimplementable since it involves tiny rotations. But Coppersmith pointed out in 1994 (https://arxiv.org/abs/quant-ph/0201067) that Shor works _without_ the tiny rotations.
2024.01.02 17:13:05: New blog post "Double encryption: Analyzing the NSA/GCHQ arguments against hybrids." https://blog.cr.yp.to/20240102-hybrid.html https://blog-cr-yp-to.viacache.net/20240102-hybrid.html #nsa #quantification #risks #complexity #costs
2023.12.19 09:04:24: New KyberSlash resource page about Kyber libraries using divisions on secret inputs and thus leaking secret information into timings in various environments: https://kyberslash.cr.yp.to Tracks various Kyber libraries to see which ones have this division and which ones have patched.
2023.12.17 20:29:35: GCHQ claims cryptosystem X has "significantly more complexity" than cryptosystem Y. Do you find yourself asking for quantification? New paper "Analyzing the complexity of reference post-quantum software": https://cr.yp.to/papers.html#pqcomplexity Spinoff: found timing leaks in most Kyber software.
2023.12.08 20:00:24: Cost exponents for lattice attacks continue their relentless march downwards. New paper "Asymptotics of hybrid primal lattice attacks": https://cr.yp.to/papers.html#hybrid https://cr-yp-to.viacache.net/papers.html#hybrid Was tempted to add a picture of the mascot for lattice-based cryptography: a slow-boiled frog.
2023.12.06 14:14:34: Have you run into people hyping the costs of post-quantum encryption? Do you find yourself wondering what the actual costs are for various cryptographic applications? I have a new paper "Predicting performance for post-quantum encrypted-file systems": https://cr.yp.to/papers.html#pppqefs
2023.11.26 21:51:34: In case it's useful for more people, posted a small script built on top of pypdf (https://github.com/py-pdf/pypdf) to magnify giant-margin conference/book PDFs into reasonable-margin PDFs, while preserving hyperlinks (unlike pdfjam) and anchors. More information: https://cr.yp.to/2023/magnifypdf-20231126.html
2023.11.25 20:56:29: New blog post "Another way to botch the security analysis of Kyber-512": https://blog.cr.yp.to/20231125-kyber.html https://blog-cr-yp-to.viacache.net/20231125-kyber.html #nist #uncertainty #errorbars #quantification
2023.11.23 21:56:17: New paper "Quantifying risks in cryptographic selection processes": of the 69 round-1 post-quantum submissions, 48% are broken by now (smallest parameters known easier to break than AES-128); of those unbroken in round 1, 25%; of those picked by NIST, 36%. https://cr.yp.to/papers.html#qrcsp
2023.10.23 18:33:51: New blog post: "Reducing 'gate' counts for Kyber-512: Two algorithm analyses, from first principles, contradicting NIST's calculation." https://blog.cr.yp.to/20231023-clumping.html #xor #popcount #gates #memory #clumping Also via Cloudflare given the frequent DoS attacks: https://blog-cr-yp-to.viacache.net/20231023-clumping.html
2023.10.13 14:38:24: Regarding the ad-hominem attacks that have just been posted by @matthew_d_green on Mastodon and on Twitter, I've replied directly to each of his Mastodon postings with easily verifiable facts to the contrary, and will be happy to engage in followup discussion there.
2023.10.06 11:37:32: For obsolete attacks from 2020, https://web.archive.org/web/20230310174959/https://pq-crystals.org/kyber/data/kyber-specification-round3-20210804.pdf estimates "2^151 gates" in "RAM model" break Kyber-512. NIST says memory adds "40 bits": 2^191. NIST waves at https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf, but Table 2 there estimates that if you scale up to sntrup653 then memory costs 2^169.
2023.10.06 11:02:01: For people who haven't had time to read the full analysis, here's something much shorter: I sent a message https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/iLA0ErnMAwAJ to NIST's mailing list spelling out how NIST's "40 bits of security more than would be suggested by the RAM model" claim fails a simple sanity check.
2023.10.05 20:16:54: Saw a Micciancio slide in an Intel event today advertising Kyber's sizes specifically for Kyber-512. Glanced at a NIST draft standard that includes Kyber-512. Then heard online that overestimating Kyber's security level is ok since everyone has moved to Kyber-768. Wait, what?
2023.10.03 19:33:12: New blog post "The inability to count correctly: Debunking NIST's calculation of the Kyber-512 security level." On a related note, announces a followup FOIA lawsuit filed today. https://blog.cr.yp.to/20231003-countcorrectly.html https://blog-cr-yp-to.viacache.net/20231003-countcorrectly.html #nist #addition #multiplication #ntru #kyber #fiasco
2023.09.17 16:23:08: Plugging AES-256 into "beyond-birthday-bound security" has a lower security level and is easier to screw up than "bigger-birthday-bound security". This makes "beyond" attractive for academic cryptographers writing papers, and, as https://eprint.iacr.org/2023/1379 illustrates, for NSA etc.
2023.09.17 10:39:23: Fact check: Lattice KEMs and signatures do _not_ have the security proofs claimed by @sweis (@sweis@infosec.exchange) in https://web.archive.org/web/20230917101907/https://securitycryptographywhatever.com/2023/06/29/why-do-we-think-anything-is-secure-with-steve-weis/ ("if you could solve this average case [crypto problem] then you could solve this, worst case [SVP] which is known to be NP-hard").
2023.09.10 10:29:16: For comparison: Dustin Moody, NIST, public talk slides (https://web.archive.org/web/20230316130702/https://csrc.nist.gov/CSRC/media/Presentations/pqc-update-round-2-and-beyond/images-media/pqcrypto-sept2020-moody.pdf): "Engagement with community and stakeholders. This includes feedback we received from many, including the NSA. We keep everyone out of our internal standardization meetings and the decision process."
2023.09.10 10:12:29: NSA's secret members of pqc@nist.gov team: Nick Gajcowski; David Hubbard; Daniel Kirkwood; Brad Lackey; Laurie Law; John McVey; Scott Simon; Jerry Solinas; David Tuller; later Rich Davis. Jacob Farinholt was Naval Surface Warfare Center, US Navy. Not sure about Evan Bullock.
2023.09.10 09:39:16: https://web.archive.org/web/20230910091944/https://csrc.nist.gov/CSRC/media/Events/ISPAB-MARCH-2014-MEETING/documents/a_quantum_world_v1_ispab_march_2014.pdf says author is "Post Quantum Cryptography Team, National Institute of Standards and Technology (NIST), pqc@nist.gov". FOIA results have revealed secret pqc@nist.gov team members in early Sep 2016, after draft NISTPQC call: more NSA people than NIST people.
2023.09.06 17:58:26: My new report "Papers with computer-checked proofs" gives "case studies supporting the hypothesis that it is often affordable for a paper presenting theorems to also include proofs that have been checked with today's proof-checking software": https://cr.yp.to/papers.html#pwccp
2023.08.18 16:29:04: Just uploaded new version of my paper "Understanding binary-Goppa decoding": https://cr.yp.to/papers.html#goppadecoding Includes detailed comparisons of all ten theorems to formalizations of the theorems in HOL Light and in Lean. Also explains how to run HOL Light and Lean to verify the proofs.
2023.08.11 20:36:50: Now posted HOL Light formalizations of the same theorems about decoding Goppa codes: https://cr.yp.to/2023/lightgoppa-20230811-verify.html (https://cr-yp-to.viacache.net/2023/lightgoppa-20230811-verify.html via Cloudflare). More verbose than the Lean versions, but took me less time to write. Which will be a better foundation for software verification?
2023.07.26 13:46:28: Formally verified theorems about decoding Goppa codes: https://cr.yp.to/2023/leangoppa-20230726-verify.html This is using the Lean theorem prover; I'll try formalizing the same theorems in HOL Light for comparison. This is a step towards full verification of fast software for the McEliece cryptosystem.
2023.06.30 10:43:22: lib25519-20230630 with new code from Kaushik Nath for batch nP (e.g., Tiger Lake: 22 kcycles!) and multi-scalar mult: https://lib25519.cr.yp.to https://lib25519-cr-yp-to.viacache.net Also CLI, infrastructure improvements, Alpine/musl support. Still needs more auditing and formal verification.
2023.06.27 14:14:28: "We operate transparently." FOIA lawsuit docs so far: first evasion (copies of public docs), then much more interesting secret slides, and now a month of secret email, including scheduling 12 Jan 2016 meeting with NSA, 26 Jan 2016 meeting with NSA, 2 Feb 2016 meeting with GCHQ.
2023.06.26 02:30:49: Here's a cryptosystem as an attack challenge: implementable PQ ECDH NIKE! Use n = 2^32-5; Koblitz curve over F_{2^n}; type-2 ONB; T = Frob; secret exponent (1+T^r1)...(1+T^r64)T^r0+T^r65+...+T^r96. Basic Shor is too slow even for 2^r1+...+2^r64, group F_{2^n}^*. Note 2n+1 factor.
2023.06.19 10:57:42: Wow, finally an honest version of FrodoKEM! New paper https://eprint.iacr.org/2023/947 from Joel Gärtner proves that 2^128 QROM IND-CCA2 security for dimension 79510 with 37-bit modulus follows from a reasonably conjectured quantitative hardness assumption for worst-case approximate SIVP.
2023.06.16 00:35:10: https://viacache.net now redistributes the cr.yp.to web pages via Cloudflare. For example, latest NSA/NIST FOIA results: https://nist-pqcrypto-org.viacache.net/foia/index.html libmceliece: https://lib-mceliece-org.viacache.net "Turbo Boost: How to perpetuate security problems": https://blog-cr-yp-to.viacache.net/20230609-turboboost.html
2023.06.16 00:28:22: Given yesterday's 18-hour DoS attack against the cr.yp.to network, I'm reposting recent links. Latest NSA/NIST FOIA results: https://nist.pqcrypto.org/foia/index.html libmceliece: https://lib.mceliece.org "Turbo Boost: How to perpetuate security problems": https://blog.cr.yp.to/20230609-turboboost.html
2023.06.14 12:26:39: Pleased to announce CryptAttackTester, a framework to systematically catch bugs in cryptanalysis. CAT tests analyses of completely specified algorithms in a simple, fully defined cost metric. Includes many ISD attacks + AES-128. Joint work with @TungChou1. https://cat.cr.yp.to
2023.06.12 09:48:22: libmceliece now available from https://lib.mceliece.org for post-quantum encryption with Classic McEliece, wrapping fast code from @tungchou1 + me. Simple stateless wire-format API and CLI. Automatic run-time selection of implementations: unified binary works with or without AVX2.
2023.06.09 12:10:47: New blog post "Turbo Boost: How to perpetuate security problems." https://blog.cr.yp.to/20230609-turboboost.html with special guest appearances from Shark, Fluffy, and Turbo Boost Max Ultra Hyper Performance Extreme. #overclocking #performancehype #power #timing #hertzbleed #riskmanagement #environment
2023.05.29 16:57:36: Exercise in systems engineering: What's the best fix for https://github.com/cloudflare/circl/security/advisories/GHSA-2q89-485c-9j2x? Change the Kyber and FrodoKEM software? Change the RNG to a simpler randombytes() API that guarantees callers won't see this failure case? Crypto students aren't taught how to think this through.
2023.05.19 03:36:11: Called AT&T to check on promised tech visit to restore home Internet. Turns out they silently cancelled visit. More calls. Finally they turn Internet back on. AT&T social-media manager wants me to change name "AT&T Victim #31415926". Sorry, no name-change techs available today.
2023.05.16 00:47:15: Fifth day of no Internet at home. Starting to work on new slogans for AT&T: "Immobilizing your world." "Reach out, reach out, and, sorry, still no Internet." "Not technically a monopoly since 1984." "Rethinking theft." "Being offline is good for you." "Internet is the I in AT&T."
2023.05.12 15:09:48: Update for everybody asking: @ATThelp has been useless. I've been paying AT&T $100/month for Internet service; two days ago AT&T deliberately turned it off with no prior notice, and AT&T continues refusing to turn it back on. @TMobile has been a lifesaver but wireless has limits.
2023.05.10 15:40:22: AT&T turns off my Internet service without warning and claims "Per your request, AT&T Internet Service has been placed on Voluntary Suspend". Over phone, @atthelp admits this is "involuntary fiber migration" and refuses to turn service back on until a tech visit (>1 week wait).
2023.04.16 21:11:27: New formally verified proof of #safegcd iteration bound: https://cr.yp.to/2023/hull-light-20230416.sage (script for full run+extras: https://cr.yp.to/2023/hull-light-howto-20230416.sh) Advantages over previous formally verified proofs: (1) covers all input sizes; (2) finishes verifying in 10 minutes; (3) smaller TCB (HOL Light).
2023.03.17 15:40:37: Major update of "Multi-ciphertext security degradation for lattices" paper: https://cr.yp.to/papers/lprrr-20230317.pdf Main optimization is integrated into the central theorem statement, backed by a proof (https://cr.yp.to/2023/lprrr-20230317.ml) verified by the HOL Light theorem prover (https://www.cl.cam.ac.uk/~jrh13/hol-light/).
2023.03.06 18:06:08: After 40 messages, past the "Springer asking me for money in violation of the open-access contract" stage. Now facing the big boss: The Springer Paper Mangler. 48 hours to put Humpty Dumpty back together OR ELSE. Original: https://s-unit.attacks.cr.yp.to/abeliannorms-20220731.pdf Mangled: https://s-unit.attacks.cr.yp.to/springer-paper-mangler-20230306.pdf
2023.02.26 14:39:54: Mini-McEliece challenges 1223, 1284 from https://decodingchallenge.org/goppa were solved in a Eurocrypt 2022 paper. Have now solved the 1347 challenge... by simply running our PQCrypto 2008 software! Perfect example of how minor the algorithmic speedups have been. https://isd.mceliece.org/1347.html
2023.01.27 20:28:30: It's fascinating to see how the historical data in the bottom-left corner of the graph in https://sam-jaques.appspot.com/quantum_landscape_2022 (from @sejaques, aka @sejaques@ioc.exchange) leads readers to guess the number of years to the top right without realizing that the top right is a moving target.
2023.01.27 19:38:17: Given today's 5-hour DoS attack against my servers, here's an Internet Archive link for the updated "NSA, NIST, and post-quantum cryptography" FOIA results that I had just announced: https://web.archive.org/web/20230127171312/https://nist.pqcrypto.org/foia/ The (formerly) secret govt documents seem to be properly archived+linked.
2023.01.26 16:00:30: NIST rules say free usability is "critical". NIST could have said in 2021: NTRU is patent-free, use it! Instead secret NIST slides said, basically, "What if we ignore patents?": https://nist.pqcrypto.org/foia/index.html#20230105/KSN%20Comparison.pptx NIST delayed, then took option where patent license won't activate until 2024.
2023.01.26 15:39:01: New librandombytes: https://randombytes.cr.yp.to/ This is designed to shield applications from having to worry about random() not being very random, RAND_bytes() maybe failing, older machines not having getrandom(), /dev/urandom maybe not being initialized, /dev/random being slow, etc.
2023.01.26 00:00:14: Documents delivered in my FOIA lawsuit don't include any NSA material yet (hmmm) but are very interesting. Particularly horrifying is NIST's secret 2021 Kyber-Saber-NTRU comparison chart: e.g., credits Kyber for being used in "Cloudflare/CEPQ2" experiment. https://nist.pqcrypto.org/foia/index.html#20230105/KSN%20Document.docx
2023.01.10 05:50:11: Updated libcpucycles-20230110 now available: https://cpucycles.cr.yp.to/download.html Documentation improvements: documented cpucycles_version(), current default frequency, how PERF_FORMAT_TOTAL_TIME_RUNNING is handled. Improved uname handling. Added s390-stckf cycle counter, s390 cpuinfo parser.
2023.01.05 11:03:15: Releasing #libcpucycles library to count CPU cycles: https://cpucycles.cr.yp.to Supports counters for amd64 (both PMC and TSC), arm32, arm64 (both PMC and VCT), mips64, ppc32, ppc64, riscv32, riscv64, sparc64, and x86, plus automatic fallbacks to various OS-level timing mechanisms.
2022.12.28 18:39:09: No CCC this year but various decentralized events are happening: https://events.ccc.de/tag/remote/ The purely online event is FireShonks. @hyperelliptic and I are giving a talk there 24 hours from now: "Post-quantum cryptography: Detours, delays, and disasters" https://pretalx.c3voc.de/fire-shonks-2022/talk/B7GMAL/
2022.12.23 11:00:51: Still needs auditing and formal verification, but happy to announce availability of lib25519-20221222. Includes extensive new speed work from Kaushik Nath: e.g., on Skylake, 30 kcycles for DH keygen, sig keygen, signing; 90 for DH shared secret; 110 verif. https://lib25519.cr.yp.to
2022.11.14 16:12:34: New paper "Multi-ciphertext security degradation for lattices" identifies several gaps in provable-security claims for lattice systems, and drives attacks through those gaps. https://cr.yp.to/papers.html#lprrr The easy part is disproving FrodoKEM's still-not-withdrawn "large margin" claim.
2022.11.14 16:24:28: The hard part is showing that, under the (shaky!) heuristics used today to claim lattice security levels, the error distributions in New Hope and Kyber allow an asymptotically faster attack breaking one out of many ciphertexts, contrary to a (flawed!) proof claim at ACM CCS 2021.
2022.11.14 16:36:48: Quantifying the impact on Kyber-512 would be even harder than quantifying the cost of single-target attacks against Kyber-512, which in turn is an unstable, challenging research topic. NIST is grossly misleading users when it labels Kyber's 2020 security analysis as "thorough".
2022.11.04 05:18:32, replying to "René Mayrhofer 🇺🇦 🇹🇼 (@rene_mobile)": There's an edge of the software ecosystem that has to parse UTF-8 for display etc in any case, but there's also a split between networking contexts that use UTF-8 and networking contexts that use Punycode, forcing every piece of software at the boundary to convert back and forth.
2022.11.03 12:46:15: 20 years ago, when the IETF was building Punycode instead of mandating UTF-8, I thought they were being remarkably stupid, and said so publicly. Later I started understanding the basic incentives. Simple, boring, working systems mean less money for standardization organizations.
2022.10.31 21:49:20: FrodoKEM documentation claims that "the FrodoKEM parameter sets comfortably match their target security levels with a large margin". Warning: That's not true. Send 2^40 ciphertexts to a frodokem640 public key; one of them will be decrypted by a large-scale attack feasible today.
2022.10.31 21:54:38: This attack does _not_ rely on a subsequent protocol exposing AES-128 ciphertexts for a common plaintext, a typical way that AES-128 keys are exposed to multi-target attacks. The attack is directly against the FrodoKEM ciphertexts. Randomizing AES modes doesn't help at all here.
2022.10.31 22:09:58: NIST discarded FrodoKEM for performance reasons, but praised its security at length. Various other organizations are continuing to consider FrodoKEM because of its reputation as the most conservative lattice system. So it's worrisome to see FrodoKEM making false security claims.
2022.10.19 19:00:29: More document releases forced by the "NSA, NIST, and post-quantum cryptography" lawsuit: https://nist.pqcrypto.org/foia/index.html These include internal NIST slides marked "not for public distribution". Meanwhile NIST repeatedly claimed in public that this was an "open and transparent" project.
2022.10.06 13:57:08: Index of records received so far in response to "NSA, NIST, and post-quantum cryptography" FOIA filing: https://nist.pqcrypto.org/foia/index.html Zero records were delivered between the FOIA filing (March 2022) and the lawsuit filing (August 2022). Obviously many more records are still to come.
2022.10.06 14:25:49: It's striking that various slide sets (BIKE summary, BIKE vs. HQC summary, summary of the BDGL algorithm, etc.) list just _one_ author. Does this mean that NIST assigned each input to just _one_ employee to read and summarize, with no protection against errors and possible abuse?
2022.10.06 14:31:43: From an error-correction perspective, having multiple readers of each input would have still fallen short of having summaries promptly posted for public review (what one would expect for an "open and transparent" project), but would have been a big step up from just one reader.
2022.09.03 13:22:00: Last year I had a paper rejected on a non-isogeny-based proposal (not announced yet; have been prioritizing other things) for non-interactive post-quantum key exchange. Here are some review quotes illustrating how incompetent the cryptographic community is at risk management.
2022.09.03 13:22:02: "Jao and Urbanik in Mathcrypt 2019 proposed a post-quantum NIKE based on SIDH" allegedly much faster than this new proposal X. "And when it comes to NIKE, it seems vanishingly unlikely that ... attacks against isogenies will improve to the point where they become slower" than X.
2022.09.03 13:22:04: "Vanishingly unlikely"? A year later, almost the entire mountain, or maybe I should say volcano, of SIDH/SIKE proposals has exploded into ashes. CRS/CSIDH is qualitatively different and still doing fine, but would it really be _that_ surprising if there's a devastating attack?
2022.09.03 13:22:06: "Cryptographers and practitioners care about performance, and not just a little, we care a whole lot": Indeed, to the extent of advocating focusing _all_ efforts on the most efficient proposals, which experience shows is _not_ the same as minimizing risk within the user's budget.
2022.09.03 13:22:07: Here's the really disturbing part to contemplate. Is this actually incompetence? Or has the cryptographic community spent decades optimizing its practices to create frequent failures, which it then points to in its requests for funding? See Section 3.8 of https://cr.yp.to/papers.html#competitions.
2022.08.30 03:56:14, replying to "covorigin (@covorigin)": There's a parameter to tune of how many pages the process is allowed to read without having the pages checked first. For those pages, I agree that it might be good for errors caught in subsequent scrubbing to terminate the process, but I'm not sure people will be ok with this.
2022.08.30 04:00:22: What's attractive about zero access, with a page fault (in the OS sense) checking the page for faults (in the hardware sense) and only then allowing a read, is that there's a pure reduction in the error rate; nobody saying "you terminated my movie player because a pixel flipped".
2022.08.30 03:44:24, replying to "BenBE (@BenBE1987)": Would be interesting to look at speed of known techniques for RS decoding in this context. I think ~1 cycle/byte for extended Hamming (with current portable software) is fast enough to slip in unnoticed for tons of data, but something slower is probably broadly affordable too.
2022.08.30 03:35:55, replying to "Dominic White ❌ (@singe)" = "Dominic White 🎄🎅 (@singe)": Some combination of hammer detection and ECC _might_ work, but this is awfully difficult to evaluate, and papers keep showing attacks. It's much more convincing (and seems implementable: see ZebRAM etc.) to keep a physical moat, at least 1 row, between different security domains.
2022.08.30 03:15:28, replying to "Thái "thaidn" Dương (@XorNinja)": By "released", you mean "suppressed until they saw that the public had the quantum core of the attack (Eisentraeger--Hallgren--Kitaev--Song) and the applicability to lattice-based cryptography, so the only piece missing in public was the note that cyclotomic units are short"?
2022.08.30 03:20:38: That was a critical note, and the public _could_ easily have missed it for many years. But the timeline, according to GCHQ, was _not_ that GCHQ was issuing a prompt public warning. There was never an explanation of what triggered them to publish the attack at the moment they did.
2022.08.29 13:52:00, replying to "BenBE (@BenBE1987)": 4096+14 is what libsecded (from https://pqsrc.cr.yp.to/downloads.html) does for 4096 bytes. Can de-interleave into original page + checksums. It's SECDED on the bottom bit of each byte, SECDED on the next bit of each byte, etc. Mixing bits can give better error correction for the same space.
2022.08.29 13:25:45: Given the current reality of desktops/laptops/smartphones almost never having ECC RAM, I'd love to see more operating-system support for periodically sweeping through pages to detect and correct errors, storing (say) 14 bytes of error-correction data for each 4096-byte page.
2022.08.29 13:44:13: It's hard for the OS to do anything useful to correct errors in pages being actively written, but that's not most pages at most times. The OS can try marking a page as read-only (or, more robust, zero access); compute the error-correction bits; periodically check for errors.
2022.08.29 10:29:51: New paper "A one-time single-bit fault leaks all previous NTRU-HRSS session keys to a chosen-ciphertext attack": https://cr.yp.to/papers.html#ntrw Attack was enabled by a change to NTRU-HRSS in 2019. Attack software (using a simulated DRAM fault): "attackntrw" from https://pqsrc.cr.yp.to/downloads.html
2022.08.29 03:49:02, replying to "Dominic White ❌ (@singe)" = "Dominic White 🎄🎅 (@singe)": The portable code in libsecded is roughly 1 cycle/byte on current Intel CPUs (depending on array size), which is the sort of cost most applications don't notice even if it's applied to all data. Certainly interesting to try larger-distance codes. But need isolation vs Rowhammer.
2022.08.29 03:21:52, replying to "John Carlos Baez (@johncarlosbaez)": Define T = cost(brute-force search for all AES-128 keys). There are finitely many algorithms A with cost(A) <= T; cost includes len(A). Compute exact success probability of each A by running A on all sequences of coin flips of length fitting into cost T. Reflect into a proof. QED
2022.08.29 03:09:53, replying to "John Carlos Baez (@johncarlosbaez)": Your parenthetical sentence here is false. For example, there exists a proof of the minimal cost of an AES-128 attack, with standard formalizations of "cost"+"attack"+"proof". We don't know if there's a proof of length <2^L for any useful value of L; that's a different question.
2022.08.28 08:33:42: Bits in DRAM sometimes flip. Typical servers have SECDED ECC DRAM to protect against this, but typical desktops/laptops/smartphones don't. Have released a "libsecded" micro-library with secded_encode() to protect an array and secded_decode() to recover it: https://pqsrc.cr.yp.to/downloads.html
2022.08.28 08:39:02: Of course, have to worry about the possibility of bugs in libsecded doing more damage than bit flips. The software passes many tests (and is also checked against a simpler Python implementation), but those aren't comprehensive. Planned formal verification is still future work.
2022.08.22 19:17:26, replying to "nikita borisov (@nikitab)": No, "specific data values may delay instruction retirement by, at most, one cycle" in https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html is a pipeline effect. Also says Skylake "may" do this for "at least" one insn in a list of (basically) vector mul. CacheBleed showed exploitability of 1-cycle variations.
2022.08.22 19:22:24: This is reminiscent of the FPU on the IBM PowerPC RS64 IV taking an extra cycle to multiply by 0; see warning at the bottom of page 10 of https://cr.yp.to/ecdh/curve25519-20060209.pdf. Figuring out values that trigger a Skylake slowdown could enable attacks along the lines of https://www.iacr.org/archive/crypto2008/51570222/51570222.pdf.
2022.08.22 19:31:09: It's easy to see how cutting corners in hardware for floating-point normalization would explain the slowdown on that PowerPC. Intel seems to say that its vector fp mul _is_ constant-time; but maybe the way that the vector int mul reuses the vector fp mul is creating a slowdown.
2022.08.22 11:28:03: The documentation actually suggests, but doesn't quite say, that, already on Skylake, vector multiplications (used in many crypto implementations) _aren't_ constant-time. Since then I've been doing various scans to try to find inputs triggering variations; nothing to report yet. https://twitter.com/agl__/status/1561374336014901249
2022.08.18 21:01:22: Hey, math profs, in case you missed it, there are exciting opportunities available to take some time working with NSA on secret problems: "We established a sabbatical program to allow mathematicians to visit us while retaining their academic affiliation" https://web.archive.org/web/20220309091131/https://www.d.umn.edu/~jgallian/PURMweb/NSA.pdf
2022.08.18 21:28:28: According to https://mathbabe.org/2012/08/25/nsa-mathematicians/ the information about how your work will be used is "cleansed" so you'll be free to imagine that it's legal, ethical, etc. Sure, the same government does some horrifying things, but surely _your_ work will only be used for the good stuff.
2022.08.18 21:33:03: Also, whatever you've heard about a lifetime post-employment obligation, upheld by the courts, to show NSA anything you're thinking about publishing so they can censor the parts they want to keep secret: Stop worrying. You're smart enough to find non-crypto problems to work on.
2022.08.18 16:49:27, replying to "Damien Robert (@GondoPloum)": Can you lift this to a computation on ideal classes, so as to be able to quickly handle (e.g.) any given supersingular curve over F_p after curve-independent precomputation?
2022.08.18 04:14:33, replying to "Anton Tutoveanu (@AntonTutoveanu)": The three NIST reports have 14 authors. Not all worked on this full-time for six years, but presumably total work is in the ballpark of 10000 days, i.e., 60 days per report page. There are many NIST references to further information the public hasn't seen, such as NSA "feedback".
2022.08.18 03:33:46, replying to "Probabilita (@kora@chaos.social) (@dakoraa)": Sure, some public comments sound like that. But many others are directly on topic, expressing concern about what NSA is doing, based on what NSA is known to have done before. https://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html: "covertly influence and/or overtly leverage" designs to make them "exploitable".
2022.08.07 20:51:19, replying to "Nadim Kobeissi (@nadim@symbolic.software) (@kaepora)" = "Nadim Kobeissi (@kaepora)": An attack agency that hires all the cryptanalysts in advance doesn't need to worry about trying to suppress public attack knowledge in other ways. In reality, it isn't _all_ the cryptanalysts, but hiring Coppersmith 20 years ago was a big win for IDA, and there are many others.
2022.08.07 20:58:39: NSA advertises itself as the largest employer of mathematicians in the country. They also offer summer jobs for US university mathematicians excited by the idea of working on secret problems. Don't underestimate the resources of a multi-billion-dollar-a-year government agency.
2022.08.07 20:15:37, replying to "Nadim Kobeissi (@nadim@symbolic.software) (@kaepora)" = "Nadim Kobeissi (@kaepora)": Certain people are falsely attributing to the blog post an inflammatory bribery claim. I never made that claim, in the blog post or anywhere else. The claim is totally out of whack with what the blog post explicitly says. Read for yourself; don't get suckered by disinformation.
2022.08.07 20:25:18: People starting from wanting to believe NISTPQC can't have been sabotaged were already making the these-are-top-experts-who-can't-have-been-bribed argument. The blog post notes this argument and then states verifiable facts trumping it, such as IDA hiring Coppersmith years ago.
2022.08.07 19:49:04, replying to "Nadim Kobeissi (@nadim@symbolic.software) (@kaepora)" = "Nadim Kobeissi (@kaepora)": "At the risk of belaboring the obvious: An attacker won't have to say 'Oops, researcher X is working in public and has just found an attack; can we suppress this somehow?' if the attacker had the common sense to hire X years earlier, meaning that X isn't working in public." 1/2
2022.08.07 19:51:00: Quote continued: "People arguing that there can't be sabotage because submission teams can't be bribed are completely missing the point. ... It's not hard to imagine that [NSA] has been pushing NISTPQC to select algorithms that NSA secretly knows how to break." 2/2
2022.08.07 06:06:11, replying to "Peter Todd (@peterktodd)": Keeping the ECC layer is critical for trustworthy protection today. But the objective of rolling out post-quantum crypto is to _also_ protect user data against future quantum computers. The ECC layer will then be broken by Shor's algorithm, and we need to get the pq layer right.
2022.08.07 05:59:14, replying to "Ben (@bytesofben)": Typical choices of 256-bit ciphers are fine; no threats on the horizon. (If you put your key on a quantum laptop and encrypt quantum data then it's likely broken, so don't do that.) 256 is overkill (looks like each qubit op will cost roughly 2^40 bit ops) but also very low cost.
2022.08.07 05:29:31: It's great to see the progress on rolling out post-quantum crypto, assuming big quantum computers are coming. The _risks_ of Kyber problems (patents, attacks) aren't a reason to incur the _definite failure_ of doing nothing. But the bleeding-edge Kyber-512 option is a bad idea. https://twitter.com/grittygrease/status/1555201358357270528
2022.08.07 05:34:37: If there's a Kyber-512 attack that scales as well as the recent SIKE attack, then, sure, Kyber-1024 is dead too. But if there's an attack that scales like core RSA attacks (NFS for integer factorization), then moving from Kyber-512 and Kyber-768 to Kyber-1024 could save the day.
2022.08.07 05:46:57: Some people say "We'll move to larger key sizes if an attack is published"; does this mean we don't care about tons of user data we're feeding into attacker databases _before_ the attack is published? Once we've sent a ciphertext, we can't retroactively add stronger protections.
2022.08.06 11:45:39, replying to "Luca De Feo (@luca_defeo)": I already mentioned the possibility of having the secret generated by (say) ANSSI. The spec could easily have required new secrets; probably this would have evolved to MPC. Would a "you're hiding an attack!" accusation deter you from adding a potentially useful extra defense?
2022.08.06 08:56:20, replying to "Anton Tutoveanu (@AntonTutoveanu)": Sure, the traditional view is that the evaluation of (proposed) cryptographic standards should assume perfect implementations, blaming the implementor for any deviations. Unfortunately, this allows a saboteur to select designs that predictably produce implementation errors.
2022.08.06 08:58:28: Rivest's 1992 critique of DSA in https://people.csail.mit.edu/rivest/pubs/RHAL92.pdf is worth reading. In particular, regarding DSA nonces, he wrote "The poor user is given enough rope with which to hang himself---something a standard should not do"; this is a useful counterpoint to the traditional view.
2022.08.06 08:39:46, replying to "Jared Flatow 🪩 (@jmflatow)": Use hybrids. Fight against NSA's "turn off ECC" pressure. Use the highest supported security levels. Measure + publicly document the percentage of your application's costs spent on cryptography. Don't condone speed being taken out of context to argue for bleeding-edge key sizes.
2022.08.05 20:43:34: New blog post "NSA, NIST, and post-quantum cryptography: Announcing my second lawsuit against the U.S. government." https://blog.cr.yp.to/20220805-nsa.html Case filed in federal court today by @LoevyAndLoevy. #nsa #nist #des #dsa #dualec #sigintenablingproject #nistpqc #foia
2022.08.02 15:08:23: You know the classic game of finding a very short Google search term that, at least for a brief moment, produces exactly one hit, for example for an amusing misspelling from people who obviously didn't bother to check their work? Try searching for "Orschoot and Weiner" in quotes.
2022.08.02 12:03:14, replying to "Luca De Feo (@luca_defeo)": No, it's not theoretical. As I said in the first message, you had the option of following a different path (ahem), generating the standard A at random by applying and then throwing away a secret isogeny. What's interesting about this is that then SIKE wouldn't (yet?) be broken.
2022.08.02 12:13:44: In other words, if current attacks are the end of the story, then pushing for elimination of back doors created a SIKE weakness that could have been avoided otherwise. Now think about this situation from the perspective of attackers who secretly knew the weakness from the outset.
2022.08.02 08:00:20, replying to "Luca De Feo (@luca_defeo)": Of course A=0 doesn't sound like a secret number. But think about the SIKE design from the perspective of an attacker whose secret knowledge was this 2022 attack. That attacker knows how to exploit A=0, and doesn't (yet?) know how to exploit an A chosen randomly by (say) ANSSI.
2022.08.01 01:28:34: Here's a funny aspect of the new SIDH/SIKE attack to think about: It seems that SIDH/SIKE wouldn't have been broken (yet?) if the proposers had applied a secret isogeny to build a standard starting curve. The attack would instead have been showing that the secret is a back door.
2022.08.01 01:33:01: See Section 5 of https://eprint.iacr.org/2020/633 for previous approaches to constructing SIDH/SIKE back doors. The new attack gives a back door for many more parameters, including parameters that look just like current SIDH/SIKE plus a defensible "we added this extra protection" tweak.
2022.08.01 01:39:22: Compare to NIST's submission criteria: "To help rule out the existence of possible back-doors in an algorithm, the submitter shall explain the provenance of any constants or tables used in the algorithm." Is it true that explaining the SIDH/SIKE constants rules out back doors?
2022.07.31 18:21:35: New paper "Fast norm computation in smooth-degree Abelian number fields": https://s-unit.attacks.cr.yp.to/norms.html Task amply studied for general number fields is much faster for cyclotomics. Critical subroutine in traditional class-group/unit-group computation, and in filtered-S-unit attacks.
2022.07.31 13:06:04: It's easy for people to issue security warnings _after_ systems are broken. What takes much more work is _proactively_ analyzing risks deeply enough to issue meaningful warnings _before_ systems are broken. Here's a 2021 example, disputing the "case for SIKE" security analysis. https://twitter.com/hashbreaker/status/1387779717370048518
2022.07.31 13:12:05: How is it possible that in 2021 there were "recent advances in torsion-point attacks" vs SIKE, while in 2022 one can find claims that there was "no attack progress" against SIDH/SIKE for a decade? There's an important lesson here about metrics for attack advances. Let me explain.
2022.07.31 13:19:45: There are some famous long-standing algorithmic problems for which there have been many attack advances and extensive evidence regarding how the advances developed. Let's take (non-quantum!) factorization as an example highlighted and studied by Gauss and many other researchers.
2022.07.31 13:30:37: How do we measure whether a factorization algorithm is better than previous algorithms? This is an important question. We don't want useless ideas to produce excitement for the attacker or fear for the defender; at the same time, we need to recognize and encourage useful ideas.
2022.07.31 13:35:30: So, okay, let's pull out the computer and try factoring random n-bit RSA moduli pq with many different factorization algorithms for various sizes of n. This immediately gives interesting information: one can easily see Pollard rho beating trial division, MPQS beating QS, etc.
2022.07.31 13:44:13: If algorithm X factors random RSA moduli faster than all previous algorithms then certainly X is an advance. This is a useful metric. But let's look at what goes wrong if we take this as the _only_ metric, dismissing any factoring algorithms that don't reduce RSA security levels.
2022.07.31 13:48:32: Pollard's p-1 algorithm established speed records for factoring _occasional_ integers. Basically, pq is vulnerable when p-1 or q-1 is a product of very small primes. It's easy to show that n-bit RSA moduli pq are extremely unlikely to be vulnerable to this unless n is very small.
2022.07.31 13:59:01: In other words, Pollard's p-1 algorithm doesn't apply to worst-case factorization. But it inspired followups replacing p-1 (from the multiplicative group) with other functions of p (from other groups). In particular, it inspired Lenstra's ECM (using elliptic-curve groups).
2022.07.31 14:03:56: ECM _does_ apply (under conjectures backed by extensive evidence) to the worst case. It's a tremendously powerful attack against RSA moduli. For (say) RSA-1024, NFS is (conjecturally) even faster, but modern versions of NFS save time using ECM as a "cofactorization" subroutine.
2022.07.31 14:13:27: Should Pollard's p-1 algorithm have been dismissed because it was useful only for occasional numbers? Of course not. The algorithm was setting speed records for some factorization problems. Algorithms for general problems are often outgrowths of algorithms for special cases.
2022.07.31 14:19:26: Is it interesting that the selected SIKE parameters maintained their security level (aside from small VoW inner-loop improvements) for a decade? Definitely. But using that as the only metric is a mistake. Torsion-point attacks were ripping more and more SIKE parameters to shreds.
2022.07.31 14:44:57: At first glance the new SIKE attack looks like a spectacular advance. But the previous work was important too! People leaping from "SIKE is maintaining its security level" to "there is no progress in SIKE attacks" were making a mistake, misextrapolating from a limited metric.
2022.07.31 15:10:52: There's more to say about how to measure special cases and use this for cryptographic risk assessment. But the starting point is to recognize that _ignoring_ special-case attacks, such as Pollard's p-1 method or previous torsion-point attacks, is a dangerous oversimplification.
2022.07.29 11:22:23, replying to "Mathias (@matthegap)": https://rump.cr.yp.to/music.html
2022.07.21 23:44:34: https://eprint.iacr.org/2022/938 uses a square-root ECDL-in-intervals algorithm (baby-step-giant-step) for reconstructing truncated signatures. Better tradeoff between cost and truncation: https://cr.yp.to/papers.html#cuberoot (with @hyperelliptic) presents a cube-root ECDL-in-intervals algorithm.
2022.07.20 08:53:07, replying to "Jethro Beekman (@JethroGB)": People often create streaming APIs, but we've seen again and again how dangerous those APIs are: applications act on streams straight from the attacker. It's much safer to have a signature on each packet. Rough analogy: put handwritten signatures on each page of a legal document.
2022.07.20 08:47:15, replying to "Ruben Kelevra (@RubenKelevra)": Yes, that's how a signed-message API works, protecting against the very common failure mode of simply skipping (or ignoring the results of) a "check a signature" call. The more advanced question is how to make it harder for people to look at sm, see where m is, and remove the s.
2022.07.20 08:22:39: If signed messages look like message+signature (as opposed to "message recovery") then it's too easy for people to grab the message and skip checking the signature. To fight against this, transform sm to obscure m: xor 1,2,3,...; better, apply any of the AONTs from Rivest et al.
2022.07.16 19:30:35: NIST's latest report (1) says NIST is confident in the security of Kyber; (2) says Kyber-512 >= AES-128; (3) says Kyber-768 >= AES-192. But attack advances keep reducing lattice security levels! It will be completely unsurprising if the next round of attacks falsifies #2 and #3.
2022.07.16 19:41:58: Do large-scale attackers (think: years of secret work by Coppersmith et al.) have _feasible_ attacks against Kyber-512? Maybe, maybe not. This is safer than the 100% security failure (assuming big quantum computers are built) of not rolling out _anything_. But "confident"? Yikes.
2022.07.16 19:45:59: _Public_ lattice attacks are super-complicated and keep getting more complicated. The 17 bullet items on pages 3-4 of https://ntruprime.cr.yp.to/latticerisks-20211031.pdf are surveying attack advances between 2018 and 2021, and we've seen more in 2022. This is completely different from the stability of ECDL.
2022.07.16 19:50:55: Here's the really weird part: https://spectrum.ieee.org/post-quantum-cryptography-nist quotes NIST's Dustin Moody as now saying "Because this is a new research field, we don’t want to put all our eggs in one basket and only have lattice algorithms, and then an attack comes along and we don’t have anything else."
2022.07.16 19:57:26: It seems that NIST _does_ see at least some of the risks in these bleeding-edge structured-lattice systems. But NIST says that "NIST is confident in the security that each provides." Confident? NIST keeps using that word. I do not think that word means what NIST thinks it means.
2022.07.07 19:36:58: Would be interested in hearing perspectives from more crypto engineers on whether the current Kyber patent status looks clear enough to proceed with deployment. Is it clear that the Ding and CNRS patents are dealt with? Is it ok that NIST hasn't commented on, e.g., CN107566121A?
2022.07.06 01:01:31: Looks like NIST didn't actually nail down the patent buyouts before announcing Kyber's selection, so now the patent holders have even more power. But, wait, NIST's expert negotiators say that they "may consider" switching to NTRU if agreements aren't signed "by the end of 2022".
2022.07.06 01:13:53: Can someone point me to where NIST's new report explains why they didn't simply select NTRU back in 2021? Is it the part where NIST says it finds the MLWE problem "marginally more convincing" than the NTRU problem? "Marginally" justifies leaping straight into a patent minefield?
2022.07.06 01:18:36: Aha, clearly this is the explanation: "A significant factor in the decision to choose KYBER over NTRU was NTRU’s performance". But wait: the same report says "KYBER, NTRU, and Saber ... Most applications would be able to use any of them without significant performance penalties."
2022.07.06 01:36:35: "Issues relating to patents were a factor in NIST’s decision during the third round as NIST became aware of various third-party patents." Actually, the CNRS patent and the Ding patent and several other patent threats were on NIST's web site in 2018, long before the third round.
2022.07.06 01:42:15: "NIST negotiated with several third parties to enter into various agreements to overcome potential adoption challenges posed by third-party patents." Where does the report evaluate the delay involved in (maybe) getting this done, and the security damage caused by this delay?
2022.07.06 01:45:11: "An evaluation factor is whether a patent might hinder adoption of the cryptographic standard." Compare to the original call (emphasis added): "it is CRITICAL that this process leads to cryptographic standards that can be freely implemented in security technologies and products."
2022.07.06 01:53:45: While all of this is going on: SLURRRRRRRRRRRRRRRRRRRRRRRRRP [that's the actual sound, amazingly the same everywhere around the world, of month after month of user data being systematically intercepted and recorded by the espionage agencies for various out-of-control governments]
2022.07.06 00:08:19: For people wondering why the Kyber team has suddenly expanded to include Jintai Ding: There's a fascinating back story. For details see my January blog post "Plagiarism as a patent amplifier: Understanding the delayed rollout of post-quantum cryptography": https://blog.cr.yp.to/20220129-plagiarism.html
2022.07.06 00:29:49: For some reason NIST left this interesting change in team composition out of its so-called "history" file https://web.archive.org/web/20220702005753/https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/round-3/history-pqc-round-3-updates.pdf, and has also now broken many links. We were watching and saved the change shortly after it happened: https://web.archive.org/web/20220622020912/https://csrc.nist.gov/Projects/post-quantum-cryptography/round-3-submissions https://web.archive.org/web/20220702005741/https://csrc.nist.gov/Projects/post-quantum-cryptography/round-3-submissions
2022.07.02 06:00:05, replying to "Greg Slepak (@taoeffect@mstdn.io) (@taoeffect)": Getting crypto to widespread deployment involves many stages (decades for ECC!). Google already tried rolling out post-quantum crypto 6 years ago and then retreated, for interesting reasons; see https://blog.cr.yp.to/20220129-plagiarism.html. OpenSSH has pq now but much more is waiting for NIST to act.
2022.07.02 02:49:44: NIST now says it plans to announce its selections of post-quantum algorithms on "Tuesday, July 5th" (I presume 2022, not 2033). Given the extent to which waiting for NIST has stalled pq deployment, this announcement is an important step forward no matter what the details are.
2022.07.02 02:52:04: Regarding details, I _hope_ that whatever NIST picked turns out to be safe, and I _hope_ that their handling of patents turns out to be adequate. If so, great: this announcement will set many more wheels in motion towards deployment of high-security post-quantum cryptography.
2022.07.02 02:54:43: But say NIST selects X, and later X turns out to be a disaster. (I question the competence of anyone who ignores this risk.) Are people then going to go back to waiting for NIST? Surely not. The announcement is getting rid of NIST's primary impact here as a deployment bottleneck.
2022.07.01 09:00:04, replying to "Erik Tews (@e_tews)": This is the multicore era. The baseline is a system with, say, 8 cores. Instead invest in 12 cores, and then recoup the investment through the power savings of running at lower speed. This generally produces better speeds for lower cost. Also, the hardware tends to last longer.
2022.06.30 18:23:03, replying to "loganaden velvindron (@loganaden_42)": There's some deployment already, yes. That's an exception to NIST's power to give away user data to attackers via delaying standardization. But at the moment most wheels in the broader ecosystem are sitting idle, waiting to spin up until NIST takes action.
2022.06.30 03:47:31: We're now up to a solid half year of delay in post-quantum standardization, apparently because NIST picked a new design in the middle of a patent minefield and was somehow confident it could instantly buy its way out of the minefield. Half a year of data given away to attackers.
2022.06.30 03:55:31: No, this isn't extra time taken for security review of submissions. NIST has repeatedly said it made its decisions long ago. Public cryptanalysts, not wanting to waste time, have a strong incentive to work on other topics until NIST reveals which submissions have been selected.
2022.06.30 04:08:59: At this point it's totally unclear what methodology, if any, NIST used to assess security risks in making its decisions. Could the differences in risks outweigh the now-guaranteed security failure of giving away half a year of user data? Did NIST's analysis include patent risks?
2022.06.30 04:17:35: NIST discouraged public patent analysis; was forced by rules to post IP statements but promptly undermined this by saying round 1 should analyze only "technical merits". And post-round 1: "we hope everyone will focus on the technical issues, rather than on the patents right now".
2022.06.30 04:26:03: Outright lie from NIST in October 2021: "For example, as Chris noted, we have not been discouraging public discussion on patent issues that may be relevant to the PQC standardization process." This was after pressure built enough that NIST had to pretend it was on top of patents.
2022.06.30 04:37:47: I sounded the alarm about post-quantum patents in 2018. NIST should have _encouraged_ public analysis of patents from the outset as an important component of decisions, instead of trying to quietly deal with patents as an afterthought to a holier-than-thou "technical" process.
2022.06.30 04:57:03: I hope we'll hear soon what the selections are, and that the buyouts have succeeded, and that the buyouts cover all the patents that matter. But this won't retroactively fix the past half year of delay, and the corresponding half year of user data that we've failed to protect.
2022.06.21 23:15:17, replying to "Jacob Christian Munch-Andersen (@NoHatCoder)": https://timing.attacks.cr.yp.to/overclocking.html already has an entry discussing masking and linking to some examples of attacks. This is a nightmare to audit, and isn't a substitute for plugging the underlying leak. Similarly, yes, some types of secrets can be erased quickly, but faster than the attack?
2022.06.21 23:19:42: It's easy to fall into the trap of thinking "This demo took 89 hours, so if this secret can be changed every day then it's safe." But we've seen again and again that initial demos are publicly superseded by much faster attacks. Large-scale attackers are probably many years ahead.
2022.06.21 07:49:22: New resource page available on timing attacks, including recommendations for action to take regarding overclocking attacks such as #HertzBleed: https://timing.attacks.cr.yp.to Don't wait for the next public overclocking attack; take proactive steps to defend your data against compromise.
2022.06.16 03:31:57, replying to "Ruben Kelevra (@RubenKelevra)": I agree that the user doesn't want to wait for the computer. I don't agree that spinning up threads on all cores needs a user-perceptible slowdown. I'm not surprised at the limited attention to super-fast browser startup: don't users normally have a browser running continuously?
2022.06.15 23:42:36, replying to "Tom (@TomInfosec)": This particular attack demo succeeded with toy models and toy signal processing, so I'd expect state-of-the-art models and state-of-the-art signal processing to extract secrets from many more programs, _except_ when users protect themselves by setting constant CPU frequencies.
2022.06.15 23:28:18, replying to "Ruben Kelevra (@RubenKelevra)": Are you waiting for your computer during these unspecified workloads? If so, shouldn't you be asking the software providers for multithreading and vectorization to make the code an order of magnitude faster, even if this makes Turbo Boost drop to 1%, as in your x265 example?
2022.06.15 23:33:54: Given how many major applications that users care about are already multithreaded and vectorized, it's wrong to cherry-pick unoptimized single-threaded applications as pictures of total system performance. This error will increase as more and more applications add optimizations.
2022.06.15 23:06:44, replying to "Ruben Kelevra (@RubenKelevra)": No, I've run various types of heavily optimized code for long periods on all cores on various Intel and AMD boxes _at base frequency_ without coming anywhere close to the thermal limits. Running at higher frequency would mean much more frequent hassle of replacing dead hardware.
2022.06.15 23:20:25: CPU manufacturers set the thermal limits on consumer CPUs to avoid obvious short-term failures. They set safer limits and frequencies on the CPUs marketed as server CPUs. It's not a coincidence that server operators frequently publish reports on observed long-term failure rates.
2022.06.15 22:49:08, replying to "Ruben Kelevra (@RubenKelevra)": Three good reasons for users to turn off overclocking: 1. Overclocking reduces the hardware lifetime; dead hardware is a hassle. 2. Overclocking is a security risk. 3. The advertised benefit of overclocking is increasingly out of whack with the real-world benefit of overclocking.
2022.06.15 10:05:22, replying to "Ruben Kelevra (@RubenKelevra)": If the user is waiting then the time is long enough that the unoptimized code with (say) 2x Turbo Boost should be replaced by optimized code with (say) 4x vectorization, 4x multithreading, even though this limits Turbo Boost. The most important bottlenecks have done this already.
2022.06.15 09:57:32, replying to "Christian Wissel (@Gnarfoz)": The claim I'm disputing isn't that turning off Turbo Boost makes something run slower. The claim I'm disputing is that turning off Turbo Boost "has an extreme system-wide performance impact".
2022.06.15 09:50:47, replying to "Gok (@Gok)": Most Intel and AMD chips at base frequency are way below thermal limits with good fans + server-room temperatures. ARM development boards tend to be harder to cool and often set their nominal frequencies too high; running the boards at lower frequencies helps them last longer.
2022.06.15 09:21:26, replying to "Ruben Kelevra (@RubenKelevra)": Your numbers seem to indicate that, on your 4-core machine, Firefox startup wasn't even managing to keep 2 cores active on average. Could this limited attention to Firefox startup optimization perhaps be a hint that most users aren't spending all day waiting for Firefox to start?
2022.06.15 09:27:50: The code that users spend the most time waiting for has much bigger incentives to be vectorized and multithreaded, even though this limits the Turbo Boost speedup. I'd expect a claim of an "extreme system-wide performance impact" to be backed by numbers for common bottlenecks.
2022.06.15 09:13:44, replying to "Gok (@Gok)": Seems to me that CPUs are generally acquiring more and more cores (even on laptops), and more and more performance-critical code is switching to using those cores, so it's becoming increasingly obsolete to declare that system performance is judged by CPUs running just one thread.
2022.06.15 09:06:35, replying to "Robert Merget (@ic0nz1)": The claim at issue of an "an extreme system-wide performance impact" is from outside researchers, not from Intel and AMD. Of course CPU manufacturers collect detailed performance evaluations regarding hundreds of ideas to see which ones will save percentages here and there.
2022.06.15 08:59:46, replying to "Ruben Kelevra (@RubenKelevra)": The claim at hand isn't that there's a measurable performance difference. The claim at hand is that there is an "an extreme system-wide performance impact".
2022.06.15 08:57:44, replying to "Gok (@Gok)": 1. Idle cores draw much less power even at full speed. 2. Almost all of my power consumption is for servers that I'm buying to get computations done (as opposed to Raspberry Pi etc for benchmarking). 3. The claim I'm disputing is about Turbo Boost, not about slow-down-when-idle.
2022.06.15 08:44:22, replying to "Ruben Kelevra (@RubenKelevra)": "Obviously"? Have you measured the difference? Would you call it "extreme"? If it turns out that you're waiting primarily for the CPU to finish web-page computations (and not the network), wouldn't the best way to reduce latency be to split those computations across _all_ cores?
2022.06.15 08:10:26: As someone who happily runs servers and laptops at constant clock frequencies (see https://bench.cr.yp.to/supercop.html for Linux advice) rather than heat-the-hardware random frequencies, I dispute the claim in https://www.hertzbleed.com that this has an "extreme system-wide performance impact".
2022.06.15 08:19:36: Using all server cores _while keeping the hardware alive for a long time_ is what gets the most computation done per dollar. My experience running >100 servers of many different types is that the best clock frequencies for this are at or below base frequency, no Turbo Boost.
2022.06.15 08:26:46: Meanwhile I'm rarely waiting for my laptop, even with it running at very low speed. I'm happy with the laptop staying cool and quiet. Yes, I know there are some people using monster "laptops" where I'd use a server, but are they really getting "extreme" benefits from Turbo Boost?
2022.06.15 08:32:25: It's easy to find Intel laptops where the nominal top Turbo Boost frequency is more than twice the base frequency. These laptops can't run at anywhere near that top frequency for optimized computations running on all cores. Where's the "extreme system-wide performance impact"?
2022.06.15 08:38:21: What I find particularly concerning about these unquantified claims of an "extreme" impact is that, in context, these claims are trying to stop people from considering a straightforward solution to a security problem. If the costs are supposedly unacceptable, let's hear numbers.
2022.06.08 01:05:01: Posted an AVX2-vectorized-sorting benchmarking script https://cr.yp.to/software/sortbench-20220607.tar.gz covering djbsort, vxsort, vqsort. (vxsort and vqsort also support AVX-512.) The middle part of this Skylake graph is the part that matters for crypto, and also the base case for larger quicksort etc. [media]
2022.06.08 01:20:21: The graph says a lot about performance. For example, the blue increases on the right are from many L1 cache misses. Maybe there has to be a tradeoff between constant-time and fast; but should try optimizing the sorting-network array-access pattern, as noted in the documentation.
2022.06.08 01:25:11: Assuming I haven't misunderstood how to use vqsort: The graph shows vqsort often losing badly to vxsort-cpp, and never beating it by much. The green mountain in the middle of the graph is a striking performance regression. Fixing it would also improve vqsort for larger sizes.
2022.06.08 01:54:22: In current vqsort, the base case is (for AVX2) a size-128 sorting network, where vqsort looks slightly better than previous work... because it fully unrolls the code for that size. Can't fit many such sizes in insn caches. djbsort and vxsort put more effort into code compression.
2022.06.08 02:05:05: Since vqsort manages to catch up to vxsort for large sizes despite being worse in the base case, the vqsort splits must be faster than the vxsort splits, so vxsort could gain speed by adopting those. For djbsort, this is ruled out by the requirement of being constant-time.
2022.06.08 02:32:08: Regarding benchmarks, it's important to realize that measuring only size 128 misses opportunities to speed up other quicksort base-case sizes, and measuring only size 1M adds unnecessary fog by adding many levels of splits to the base cases. Many sizes appear; measure them all!
2022.06.07 20:12:44, replying to "Richard Startin (@richardstartin)": When I started collecting vectorized-sorting references years ago, I quickly noticed a pattern of previous work not citing other clearly relevant previous work ... so to compensate I did _more_ searches, finding many interesting implementations and papers: https://sorting.cr.yp.to/refs.html
2022.06.07 20:20:11: Smaller searches today (on duckduckgo to avoid filter bubbles) find vxsort without trouble. It's puzzling to see Google claiming state-of-the-art speeds without a direct comparison. Also, days after being pointed to djbsort and vxsort, Google still can't manage to run benchmarks?
2022.06.07 20:01:14, replying to "Cat (@eigma)": The 16x8 clarification is useful, but the lack of timings is surprising, as is the "some use cases may be interested in smaller arrays" comment. Handling smaller arrays faster would make vqsort faster for _all_ sizes. The vqsort paper+code spend serious effort on the base case.
2022.06.05 22:07:25, replying to "Jacob Christian Munch-Andersen (@NoHatCoder)": Um, no, that's not how Intel CPUs work. Intel prioritizes speed, and then tries to reduce power without noticeable slowdowns. Agner Fog's example is AVX2 ramping up to full power in 56000 cycles and staying there unless there's _no_ 256-bit instruction for _millions_ of cycles.
2022.06.05 21:27:27, replying to "Jacob Christian Munch-Andersen (@NoHatCoder)": Um, page 155 of https://agner.org/optimize/microarchitecture.pdf reports full-power AVX2 after 56000 cycles on almost the same CPU. I measure first vqsort int32[256] call above 50000 cycles, then ~10000 for the next three runs, then rapidly settling down to around 8000. (djbsort: 4615, 2026, 1361, etc.)
2022.06.05 21:38:27: First-call performance in this type of benchmark isn't interesting for applications that keep their main-loop code size under control; that's why I reported the stable ~8000-cycle figure. For people familiar with the Skylake performance characteristics, >30 runs are ample data.
2022.06.05 21:49:48: I understand that many people aren't immersed in CPU microarchitecture, so I've now run a 3-second sequence of 1048576 calls to rdtsc+vqsort int32[256] on the same Skylake. An average call takes 8292 cycles, 6x slower than djbsort. (rdtsc and other loop overheads use <30 cycles.)
2022.06.05 22:25:29: Tweaking the bench_sort from vqsort to use M = 256 reports 364 MB/s, i.e., 8.24 cycles/byte at 3GHz, which is around 8400 cycles. M = 1024 gives 645 MB/s, i.e., 4.68 cycles/byte, above 19000 cycles. Looks like a bit more timing overhead than my vqsort test, but basically matches.
2022.06.05 18:15:39, replying to "Jacob Christian Munch-Andersen (@NoHatCoder)": Ran a loop of 33 rdtsc+vqsort, each >8000 cycles for the smaller size that I mentioned. One always expects initial calls to be outliers (not just for AVX2 ramp-up; the big starting issue is code caching); djbsort's int32-speed (https://sorting.cr.yp.to/speed.html) says medians and quartiles.
2022.06.05 18:19:57: AVX2 usage has also become so pervasive in typical code that it's not surprising for the CPU to always have the AVX2 unit warmed up; cooldown is triggered after millions of non-AVX2 cycles. But the more important point is to always check for variations across many measurements.
2022.06.05 07:57:39, replying to "Danilo (@oak_doak)": Ryzen 5 3600 is a Zen 2 chip, so (unlike Zen 3 and most Intel CPUs) it has very slow pext. Looks like vqsort's 64-bit AVX2 code blindly uses pext.
2022.06.05 07:03:08, replying to "0b0000000000000 (@0b0000000000000)": Sorting in L1 cache is the most important use case in post-quantum crypto and many other applications. It's also the base case inside vqsort, and something the vqsort paper and code put considerable effort into. The vqsort claim was "fastest", not just "fastest for large sizes".
2022.06.05 07:08:03: So far I haven't been able to verify these vqsort speed claims. On the contrary, it seems that, for 32-bit data types on AVX2, vqsort would be faster if its base-case code were replaced by a call to the 2018 djbsort code. Similarly, vqsort should reuse vxsort-cpp for AVX-512.
2022.06.05 06:51:30, replying to "Danilo (@oak_doak)": The growing corner of CPUs with AVX-512 can definitely do better with that than using similar AVX2 code, but the paper says "fastest sort for individual (non-tuple) keys on AVX2 and AVX-512", which I understand to mean fastest on CPUs with AVX-512 _and_ on CPUs with just AVX2.
2022.06.05 03:39:55, replying to "Ruben Kelevra (@RubenKelevra)": Intel Xeon E3-1220 v5, pinned at 3GHz. Turbo Boost (which would be 3.5GHz) disabled. No evidence of any AVX2 throttling. Reasonable cooling, no evidence of thermal throttling, plus these were very short single-core runs. Both of the pieces of code being benchmarked were AVX2.
2022.06.04 23:39:13: Tried Google's new vectorized quicksort code vqsort on Skylake, and timed Sorter() as ~8000 cycles for int32[256] (big chunk of code for a size-specific sorting network), ~19000 cycles for int32[1024] (non-constant-time). djbsort is 1230, 6286 (ct). Did I misuse vqsort somehow?
2022.06.04 23:44:01: I included algo-inl.h and vqsort.h, did auto s = Sorter() and SortAscending order, and then did s(x,N,order) on an array x of N int32_t values. Size seems ok; I checked that the output is sorted correctly and (in a separate run to not slow things down) that asan doesn't complain.
2022.06.04 23:50:39: I also checked in gdb that the dispatch is calling the AVX2 code (presumably the fastest vqsort option for Skylake, as opposed to machines with AVX-512 such as Skylake-X). I didn't notice an API with lower per-call overhead, and per-call can't explain the jump from 8000 to 19000.
2022.06.05 00:04:21: I also looked briefly at the vqsort paper https://arxiv.org/pdf/2205.05982.pdf, which says "outperforms state of the art architecture-specific algorithms". Section 3 describes vqsort's size-256 sorting network, but is missing microbenchmarks and comparisons to, e.g., sid1607, djbsort, vxsort.
2022.06.05 00:08:37: Oops, sorry, the "outperforms" quote is from the accompanying blog post https://opensource.googleblog.com/2022/06/Vectorized%20and%20performance%20portable%20Quicksort.html. The paper says that vqsort is "the fastest sorting implementation known to us for commercially available shared-memory machines". Should I maybe have added some extra cmake options?
2022.06.05 00:12:23: Another theory is that the speeds depend on a newer compiler version than what I tried, but this theory doesn't seem compatible with the "performance portability" and "production-readiness" parts of the advertising. I also tried a Broadwell with gcc 10.2.1, which isn't so old.
2022.06.02 17:02:50: Eurocrypt talk today on https://eprint.iacr.org/2021/1332 presented cryptosystems using lattices secretly isometric to a public easy-to-decode lattice, and portrayed this as analogous to McEliece using codes secretly isometric to a public easy-to-decode code. That's not what McEliece does!
2022.06.02 17:13:49: Beyond isometry, there are many ways to hide codes; see https://cr.yp.to/talks.html#2012.09.24 for a survey. McEliece takes a secret scaling (from the secret polynomial g), plus a subfield subcode (the scaling isn't an isometry on the resulting code), plus a permutation (the isometry part).
2022.06.02 17:23:39: This is important because if McEliece relied _just_ on the secret isometry (the permutation) then it would be broken by Sendrier's 2000 support-splitting algorithm. Now a new proposal relies purely on secret isometries, misrepresents McEliece, and downplays Sendrier? Alarm bells!
2022.06.02 17:35:17: Meanwhile the trend in code-based cryptography is to add _more_ defenses against potential attacks. For example, Classic McEliece describes secret puncturing, taking the code length n below a power of 2, as an "extra defense", and uses this for most proposed parameter sets.
2022.06.02 17:58:49: Secret puncturing can't hurt security. The 2012 challenge to break a secretly punctured secretly permuted symmetric public code (BCH) is designed to shed light on whether secret puncturing helps security. Secret puncturing is then layered _on top_ of McEliece's original defenses.
2022.06.01 19:16:00: Yet another paper appears claiming to chop a further percentage out of lattice security levels against quantum attacks: https://eprint.iacr.org/2022/656 But we keep hearing that we're not supposed to worry about continual lattice security degradation. Let's look at the logic behind this.
2022.06.01 19:22:57: First of all, we're told to ignore the (im)maturity of the security analysis, as reflected by the (in)stability of quantitative security levels. Quantification is dumbed down into a yes/no question: is this attack as expensive as a brute-force attack against a single AES-128 key?
2022.06.01 19:28:13: Max cost of an AES-128 key search is 2^128 AES evaluations, about 2^143 bit ops. Quantum attacks sound much cheaper, about 2^64 quantum AES evaluations, but we're not supposed to worry: a qubit op probably costs roughly 2^40 bit ops; also, P-way parallel attacks gain only 2^64/P.
2022.06.01 19:32:37: Whenever there's an improved quantum attack against lattices, we're told to ignore it because (1) the speedup is still smaller than the quantum AES speedup; (2) the lattice parameters are chosen to be as hard to break as AES-128 pre-quantum; (3) ergo they're also ok post-quantum.
2022.06.01 19:45:36: But is it true that parameters are chosen this way? We already have ECC for pre-quantum security. Consider Lyubashevsky in https://archive.today/JVn42 saying that the lattice quantum speedup was "just a dozen or so bits" and, on this basis, recommending smaller lattice parameters.
2022.06.01 19:52:27: Furthermore, it's not just quantum attacks getting better. During NISTPQC, Kyber's pre-quantum AES comparison has degraded from (1) "conservative" to (2) bleeding edge in bit ops to (3) apparently broken in bit ops and bleeding edge in AT, despite tweaks to try to add security.
2022.06.01 20:23:17: The latest everything-is-fine narrative emphasizes that attacks aren't feasible yet. Cryptanalysts aren't even acknowledged for successfully breaking the original as-strong-as-AES claim. This is a big regression from the traditional emphasis on quantitative algorithm speedups.
2022.06.01 20:30:29: Systematically encouraging publication of algorithm speedups is by far the community's best way of finding out whether proposed cryptosystems are breakable. This means measuring and acknowledging the speedups, not making one excuse after another to downplay or deny the speedups.
2022.05.31 00:28:51: Very small software release showing how easy it is to beat NTL (which is faster than PARI, Sage, etc.) by a factor >100 for typical input sizes in an important subroutine, algebraic norm computation, _if_ the number field is a power-of-2 cyclotomic field: https://cr.yp.to/software/cyclo2power-20220530.tar.gz
2022.05.31 00:36:08: The basic algorithm here was already known, but previous software wasn't showing what the algorithm can accomplish. More complicated algorithms handle more cyclotomics and their subfields (number theorists say "Abelian fields") as long as the degree is smooth. Paper coming soon.
2022.05.26 22:54:16: Now posted a collection of evidence that the publication of DH was driven by the usual academic publication incentives, not by patents: https://cr.yp.to/patents/us/4200770.html As part of digging into the history, freed up various related litigation documents via RECAP: https://www.courtlistener.com/docket/10434535/schlafly-v-public-key-partners/
2022.05.26 23:09:08: Most patents that I've studied are on "inventions" that were published by other people independently, giving simpler examples of the damage done by the patent system. DH is unusual in that it wasn't published independently; that's why one has to look more closely at the history.
2022.05.26 23:18:48: Meanwhile pro-patent articles such as https://repository.law.umich.edu/cgi/viewcontent.cgi?article=1116&context=mttlr (1) say X was patented, (2) say the disclosure+deployment of X are of societal value, (3) leap to the conclusion that the patent on X was of societal value, and (4) never ask whether X would have been published anyway.
2022.05.26 20:26:24: Updated software to parse the China NHC case announcements (now more fields in output data): https://cr.yp.to/software/nhcparse-20220526.tar.gz Shanghai is down to 1% of peak from 6 weeks ago, again raising question of what the most tolerable measures would be if the goal were instead set at ensuring R<1. [media]
2022.05.25 00:51:51: "I'm not happy with the field of candidates for post-quantum public-key signature systems." 2003, in the posting that introduced the "post-quantum" phrase: https://archive.is/BHGOM Then https://eprint.iacr.org/2004/297 surveyed these sig systems; almost all now broken, except hash-based.
2022.05.25 01:12:29: Will today's post-quantum proposals turn out to have a better track record when we look back at them 18 years from now? Some people sound awfully confident in supposed dividing lines between new structured-lattice systems and old broken structured-lattice/structured-code systems.
2022.05.25 01:25:43: When there's a long history of cryptographic failures, is this because there are a dozen pitfalls surrounding a safe core idea? Or is the core idea fundamentally flawed? It's deeply disturbing to see cryptographic decisions being made by people who think these are easy questions.
2022.05.21 19:17:21, replying to "Shawn Willden 🇺🇸 🇺🇦 (@shawnwillden)": Would you say that "any organization that runs high-value edge- and cloud-computing applications that require large volumes of data to flow quickly between local nodes and decentralized sources of computing power" is facing the performance challenges of crypto on small devices?
2022.05.21 18:58:20: Management consultant Dogbert says that post-quantum cryptography is "impractical" for "high-value edge- and cloud-computing applications that require large volumes of data to flow quickly between local nodes and decentralized sources of computing power": https://web.archive.org/web/20220521163740/https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/when-and-how-to-prepare-for-post-quantum-cryptography
2022.05.21 19:04:54: After this performance BS and generic emerging-market FUD (unspecified "cost" and the risk of "having to switch to higher-performance PQC solutions that come to market in the future"), Dogbert concludes "most organizations should take a wait-and-see approach to PQC solutions".
2022.05.09 18:33:26: 2018, e.g. in https://www.imperialviolet.org/2018/04/11/pqconftls.html: Many cryptographers are blaming subtle overflow bugs on ECC carry chains. 2022, https://github.com/mupq/pqm4/issues/226: Subtle overflow bug in some Kyber code. Zero impact today, but we're about to see an explosion of lattice deployment and many more bugs.
2022.05.09 14:31:27, replying to "Rich Felker (@RichFelker)": I should emphasize that my question is about the population-level numbers. Examples of boosted people dying don't say that vaccines are useless; similarly, "here are examples of reinfections" isn't the same as "here are millions of new #LongCOVID cases after you said it's over".
2022.05.09 13:53:30, replying to "M:\arc -de B (@marcdeb)": The question about whether there will be millions of new #LongCOVID cases each year is a question about US numbers. The analogous worldwide question would say tens of millions but has less supporting data: studies of #LongCOVID prevalence typically focus on specific countries.
2022.05.09 14:09:42: COVID deaths should be relatively easy to track, but recent reports claim that some big countries have been undercounting deaths by an order of magnitude, versus ~1.2x in the US. Less severe infections are seriously undercounted in the US but wastewater data is readily available.
2022.05.09 03:52:19, replying to "Gordon Mohr | gojomo.eth ꧁ꙮꙮ꧂ (@gojomo)": The vaccination numbers and past-infection numbers are of course relevant, and were already taken into account in the question at the top of the thread.
2022.05.09 03:48:50, replying to "Gordon Mohr | gojomo.eth ꧁ꙮꙮ꧂ (@gojomo)": Another random example claiming "The Omicron wave will leave most people with potent and durable protection against Covid": https://www.wsj.com/articles/herd-immunity-is-over-superimmunity-covid-omicron-immune-system-virus-variants-antibody-antibodies-11642448736 This once-and-done belief is driving COVID (in)action today in the US. But what happens if it fails for millions of people per year?
2022.05.09 03:34:23, replying to "Gordon Mohr | gojomo.eth ꧁ꙮꙮ꧂ (@gojomo)": Example of a popular Twitter account stating a policy rationale where (1) the resulting actions are indistinguishable from today's mainstream COVID actions and (2) the rationale focuses exclusively on the percentage of people who have caught COVID so far: https://twitter.com/VPrasadMDMPH/status/1522364854585085952
2022.05.09 01:48:04: Is there any scientific basis for today's "Catch COVID once and that's the end of it" narrative? Why shouldn't COVID mutations keep escaping immunity, creating big new waves every year that, in the US, kill hundreds of thousands of people and inflict #LongCOVID on millions more?
2022.05.09 02:31:29: There's ample evidence of vaccination reducing typical severity + reducing #LongCOVID rates, but reducing isn't eliminating. Mutation is now much faster than vaccine updates. Improved treatments have been reducing short-term death rates but so far doing little against #LongCOVID.
2022.05.09 02:45:39: If another big wave brings millions of new #LongCOVID cases, will the it's-over narrative disintegrate? Or will we see more downplaying and denial (there aren't many of these people, they're imagining their symptoms, etc.), and vociferous insistence that nothing else can be done?
2022.05.07 14:42:53: "Math doesn’t seem to care very much about the energy budget of an earth sized planet or how many atoms are in its crust, so if your claim to have a large security margin relies crucially on exceeding some such physical limit, you might not have as much as you think." (NIST 2020)
2022.05.07 14:58:11: 2022, after attack advances appear to show that NSA's favorite candidate flunks NIST's minimum security requirements: "realistic ...?", "42% of the width of Planet Earth", "small-moon-sized cryptanalytic device", "importing matter from other solar systems", etc., etc., etc.
2022.05.07 15:08:45: The same submission also offers larger keys (which have also been losing security), but continues to exploit smaller keys to attract attention in benchmarks. NIST, continuing to play both sides of the bait and switch, plans to avoid specifying key sizes in its next announcement.
2022.05.06 22:57:49: Shanghai's actions are now chopping Omicron BA.2 infections in half every week. Suppose the goal is instead set at reducing infections by 20% per week; is it hard to imagine that this loosening would allow quarantine at home, normal food deliveries, etc.? (And no killing pets!) [media]
2022.05.06 23:53:01: It's important to be able to quantify how different factors affect spread (as @tomaspueyo pointed out long ago). Surely limiting contact between people helps, but how much? How much spread comes from restaurants doing only deliveries? How does home quarantine compare to central?
2022.05.07 01:20:28: Pre-lockdown, with whatever baseline impact from masks + Chinese vaccines, Shanghai cases were growing ~4x/week, so overall the lockdown reduced spread by ~8x/week (probably between 2x and 3x per serial interval). This came from several factors, so R<1 didn't require all factors.
2022.05.07 01:32:38: Meanwhile most Americans seem to think that Omicron is a superbug that leaps from one building to another without human assistance and wasn't stopped by Shanghai's lockdowns. People don't ask "What's the most tolerable way to stop Omicron's spread?" if they think it's impossible.
2022.05.03 22:49:12: Now open-sourced updated software to parse the NHC announcements: https://cr.yp.to/software/nhcparse-20220503.tar.gz This extracts + graphs important data that's missing from the @JHUSystems database (and thus Google's case graphs), notably the total per-region (e.g. Shanghai) cases including asymptomatic. https://twitter.com/hashbreaker/status/1520836496609071104
2022.05.03 22:57:58: Improvement vs. graph I posted earlier: parsing now extracts and subtracts the cases-converted-from-asymptomatic-to-symptomatic from the total symptomatic+asymptomatic. (Conversions aren't new cases. ~40% of news articles get this wrong.) This noticeably changes Shanghai graphs. [media]
2022.05.01 20:44:11: Plotted the Shanghai case numbers (total symptomatic+asymptomatic) extracted from http://www.nhc.gov.cn/yjb/pzhgli/new_list.shtml. Found it somewhat annoying to automate this extraction: Chinese is ok, frivolous JS is ok, but kept getting 412 (even with pyppeteer), plus had to parse semi-free-form text. https://twitter.com/hashbreaker/status/1512864666413723649 [media]
2022.05.01 21:00:22: Google's plot of Shanghai cases (https://www.google.com/search?q=shanghai+covid+cases) does some of the same thing but covers only symptomatic cases. What's most useful about the Shanghai data is the direct evidence from mass testing; PCR tests don't measure the split of cases into symptomatic+asymptomatic.
2022.05.01 21:06:12: There's another part of the reports saying that N of the symptomatic cases were previously asymptomatic; these should be taken away from the totals, but I haven't scripted this yet. N is generally in the ballpark of 1000, which is now a noticeable fraction of the Shanghai cases.
2022.04.24 23:06:02: How does a journalist end up believing and writing that "cases continue to grow in Shanghai, despite a failed weeks-long lockdown that has brought the financial hub to a halt"? https://edition.cnn.com/2022/04/24/china/beijing-covid-outbreak-lockdown-fears-intl-hnk/index.html The peak of reported Shanghai cases was 10 days ago, 30% more cases than today.
2022.04.24 23:18:05: Regarding deaths, the article correctly says "questions have been raised about whether the numbers account for all fatalities"; maybe the journalist disbelieves the tallies of _total_ cases; does the article say "reported cases are dropping but maybe real cases are rising"? No.
2022.04.17 18:15:44, replying to "Nick Bouliane 🦈 (@nicboul)": A trie looks up string x by taking node0 = root, node1 = node0.child(x[0]), node2 = node1.child(x[1]), etc., each x[i] typically being a byte. A crit-bit tree takes node0 = root, node1 = node0.child(x[node0.bitpos]), node2 = node1.child(x[node1.bitpos]), etc.
2022.04.13 19:07:26: I've realized that my previous tweet could be viewed as unfair to all the other smart people who went to work for IDA/CCR: e.g., Buhler (co-developed general NFS; Pollard NFS factored only special N), Gordon (first dlog version of NFS), and Miller (ECC, independently of Koblitz). https://twitter.com/hashbreaker/status/1514240328751935490
2022.04.13 15:53:22: Levchin prize at RWC 2022 to Coppersmith for foundational innovations in cryptanalysis. Now try to imagine how much Coppersmith contributed to secret attacks in the two decades after he moved from IBM to the Center for Communications Research at IDA, an NSA consulting company.
2022.04.12 19:14:40: First release of nttcompiler: https://pqsrc.cr.yp.to/nttcompiler.html Reads domain-specific language for number-theoretic transforms (NTTs) used in (e.g.) NTRU Prime, outputs optimized AVX2 code, verifies that the code works for all possible inputs. To do: more CPUs, more NTTs, more assurance.
2022.04.09 20:46:58: I understand the reports of big costs (economic, psychological, human, et al.) of China's anti-COVID actions in Shanghai, but I'm puzzled to see confident declarations that the actions are ineffective. Why is it clear that daily cases won't be much lower by the end of this month?
2022.04.09 14:07:10, replying to "Nadim Kobeissi (@nadim@symbolic.software) (@kaepora)" = "Nadim Kobeissi (@kaepora)": FOIA request prompted a release clearly covering this: "Among the remaining, structured lattice schemes, our assessment was that cyclotomics (esp power-of-2 cyclotomics) are the clear 'community standard' * So, we moved Kyber, Saber, NTRU on as Finalists, but kept NTRU prime too"
2022.04.09 14:12:18: Here's the full document (plus metadata from the relevant NIST employee saying it's in response to my FOIA request): https://archive.is/RG14h NIST had previously hidden this information about its handling of NTRU Prime. So "revealed" seems like exactly the right word.
2022.04.09 09:20:51: For all the people asking: NIST has consistently said that its first selection will be a subset of {finalists,SPHINCS+}, while other candidates such as NTRU Prime won't be eligible until 2023. A FOIA request revealed why NTRU Prime isn't a finalist; see https://ntruprime.cr.yp.to/latticerisks-20211031.pdf.
2022.04.05 10:19:55: Systematic testing yesterday in Shanghai reported 268 symptomatic cases + 13086 asymptomatic, a remarkable ratio: https://www-nhc-gov-cn.translate.goog/yjb/s7860/202204/44054290c5fd40d899c6f9a316fecf26.shtml?_x_tr_sch=http&_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp (Updates: http://www.nhc.gov.cn/yjb/pzhgli/new_list.shtml) Omicron's nasal affinity contributing to "stealth" spread? Inadequate compensation for reporting symptoms?
2022.04.05 16:52:49: Another theory (mentioned in, e.g., https://www.reuters.com/world/china/shanghai-lockdown-deepens-after-new-surge-asymptomatic-cases-2022-04-05) is that many of the asymptomatic cases are actually presymptomatic. To check this directly, would want to track finer-grained data showing how many symptomatic cases were previously labeled as asymptomatic cases.
2022.04.04 22:56:04, replying to "David Andersen (@dave_andersen)": Even without advances in semiconductors, the attack is feasible for large-scale attackers today. @LindellYehuda now claims that the attack isn't worthwhile (see "attacker economist" in https://blog.cr.yp.to/20151120-batchattacks.html), which is very different from his false claims that there's no attack.
2022.04.04 16:36:48, replying to "Yehuda Lindell (@LindellYehuda)": The third bullet item on https://blog.cr.yp.to/20151120-batchattacks.html is a large-scale but feasible (2^98-guess) attack against a batch of 2^40 AES-128 targets, expected to break roughly 2^10 targets. There's no out-of-range preprocessing. The users whose data is compromised can and should blame you.
2022.04.01 15:44:19: IACR is adopting NSA's clever solution to the cryptocurrency/cryptography conundrum: from now on, "crypto" means cryptocurrency, and "crypt" means cryptography. Next year's flagship IACR conferences will split into Crypto, Eurocrypto, Asiacrypto, Crypt, Eurocrypt, and Asiacrypt.
2022.03.31 17:43:57: NIST announces that the #NISTPQC selections will definitely be announced this month, hopefully by the 35th or 40th day of the month, although maybe later in the month. https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/fvnhyQ25jUg/m/-pYN2nshBgAJ
2022.03.29 11:32:05: Short case study of modern surveillance, written for a broad audience: https://www.nytimes.com/2022/03/28/technology/nokia-russia-surveillance-system-sorm.html Includes a few leaked documents, plus fascinating claims: "In democracies, the police are generally required to obtain a court order before seeking data from telecom service providers."
2022.03.21 17:55:40: Notes on getting copy and paste of spacing from a PDF to work well enough for Python script -> verbatim in pdflatex/lualatex/xelatex -> PDF -> Firefox -> Python script: https://cr.yp.to/2022/20220321/verbatimfile.tex Sample PDF: https://cr.yp.to/papers/goppadecoding-20220320.pdf#label-rs-algorithm Still more work to do to support other PDF readers.
2022.03.20 18:52:46: Posted new paper "Understanding binary-Goppa decoding": https://cr.yp.to/papers.html#goppadecoding This is an introduction to the decryption algorithms inside Classic McEliece (https://classic.mceliece.org), _the_ post-quantum encryption system for people prioritizing long-term security of their data.
2022.03.15 18:56:11: Filed a FOIA request "NSA, NIST, and post-quantum cryptography": https://www.muckrock.com/foi/united-states-of-america-10/nsa-nist-and-post-quantum-cryptography-126349/
2022.03.09 01:12:30, replying to "Nadim Kobeissi (@nadim@symbolic.software) (@kaepora)" = "Nadim Kobeissi (@kaepora)": Rolling out something post-quantum (on top of ECC, obviously) to _try_ to protect users is compatible with recognizing and mitigating risks (which _isn't_ the stated priority for #NISTPQC). NSA/NIST recommendations seem designed to maximize the amount of data delivered to NSA.
2022.03.08 03:04:04, replying to "Jacob Alperin-Sheriff 🐵 (@DemocraticLuntz)": To clarify, are you claiming that NIST's "reminder to not put candidates into products until the standard is done" is asking for this further delay only for hardware and not for software? If so, do you have any evidence for this claim?
2022.03.08 02:32:43: In today's #NISTPQC talk, Moody said (1) NIST will share any concrete post-quantum IP news as soon as it has it; (2) he's "happier" about IP news now than he was months ago; (3) NIST has already made its selection and is reviewing its report. So, um, did something secret happen?
2022.03.08 02:45:04: Moody also took the new Rainbow attack from @WardBeullens as an argument "to not put candidates into products until the standard is done", which Moody said would be 2023 but later said maybe 2024. Um, how about we _try_ to protect Internet users against future quantum computers?
2022.02.24 16:55:28: Happy to see the Linux RNG getting faster and, more importantly, easier for security reviewers. But let me emphasize that my blog post says "this RNG construction certainly isn't new"; e.g., mapping b-bit key to b-bit output + b-bit rekey is in the cited 2005 Barak–Halevi paper. https://twitter.com/EdgeSecurity/status/1496100508402081798
2022.02.22 11:42:12, replying to "Elichai Turkel (@Elichai2)": Within the three important types of implementations listed in Section 4.3 of https://cr.yp.to/newelliptic/nistecc-20160106.pdf, the third type is simplified by the synchronization of various details across X25519 and Ed25519, including scalar choices. Last bit 0 also eliminates a swap line in common code.
2022.02.20 10:41:24, replying to "𝖬𝖺𝗁𝖽𝗂 𝖢𝗁𝖾𝗋𝖺𝗀𝗁𝖼𝗁𝗂 $8 (@mahdi_tcs)": Don't buried disclaimers explain the origin better than hypothesizing that misconceptions inexplicably appear out of nowhere? Reader sees NP-hardness/NP-completeness name-dropped in the context of advertising provable lattice security and _presumes_ the cryptosystems are NP-hard.
2022.02.20 03:18:20, replying to "𝖬𝖺𝗁𝖽𝗂 𝖢𝗁𝖾𝗋𝖺𝗀𝗁𝖼𝗁𝗂 $8 (@mahdi_tcs)": Hmmm. Let's try an example: https://web.archive.org/web/20220104055120/https://web.eecs.umich.edu/~cpeikert/pubs/lattice-survey.pdf has a mostly clear disclaimer _on page 8_, but look at the mention of NP-completeness _in the advertising on the first page of the introduction_. Would you classify this as evidence for, rather than against, your origin story?
2022.02.19 07:36:42, replying to "𝖬𝖺𝗁𝖽𝗂 𝖢𝗁𝖾𝗋𝖺𝗀𝗁𝖼𝗁𝗂 $8 (@mahdi_tcs)": Regarding public statements/suggestions that lattice-based public-key encryption has NP-hardness proofs: 1. You seem confident in a specific narrative regarding the origin. Is this confidence based on any evidence? 2. How do you get from "misconception" to "not misinformation"?
2022.02.18 22:28:22, replying to "Lukas Prokop (@meisterluk)": Useful reading on some of the basic obstacles: https://www.iacr.org/archive/crypto2006/41170129/41170129.pdf; https://lucatrevisan.github.io/pubs/redux-sicomp.pdf. Increasing approx factors moves from NP-hard to no real hope of proving NP-hard, then to problems that break KEMs (also no hope of converse!), then to problems that have been broken.
2022.02.18 14:04:35: "Kyber is fast and its security guarantees are linked to an NP-hard problem." What is "linked" supposed to mean? The cops have discovered that Kyber's next-door neighbor's ex-boyfriend is an NP-hard problem? And we're supposed to believe this gives Kyber some sort of protection? [media]
2022.02.18 08:14:45: No. Lattice KEMs under consideration for deployment (NTRU, Kyber, Frodo, etc.) do _not_ have NP-hardness proofs. (There's also no serious hope of crossing the dividing lines.) Questions to ask: Where did the pervasive misinformation on this topic originate? Who benefits from it? [media]
2022.02.13 11:13:08: If I'm understanding this article correctly, journalist @dcastelvecchi talked to NIST, and NIST said they would announce selections of two encryption algorithms and two signature algorithms but write standards for only one encryption algorithm and only one signature algorithm. https://twitter.com/Nature/status/1491011029593169923
2022.02.09 17:05:59, replying to "Halvar Flake (@halvarflake)": See, e.g., https://twitter.com/CT_Bergstrom/status/1479938658253766657. Policymakers are typically awed by the Power of Science and won't realize that these are garbage conclusions calculated from a garbage model of testing as a process blindly carried out every N days, for example with N=7 or N=14. @ct_bergstrom
2022.02.09 17:12:56: When a case lasting 9 days is caught by a blind 14-day test, it has more than a 50% chance of being gone after another 5 days. Dress this up as a scientific report and it turns into government-policy decisions that mislead many people who were in fact tested for other reasons.
2022.01.29 17:09:08: New blog post "Plagiarism as a patent amplifier" https://blog.cr.yp.to/20220129-plagiarism.html: Understanding the delayed rollout of post-quantum cryptography. #pqcrypto #patents #ntru #lpr #ding #peikert #newhope
2022.01.20 14:55:12, replying to "Halvar Flake (@halvarflake)": Eyes on the screen at all times; no typing sounds except when specifically authorized; microphones on at all times; 3 camera directions; remote AI enforcement; local spyware enforcement; any signs of stress or darker skin and you fail the exam. Oh, wait, that's just for students.
2022.01.20 13:52:19: Heard that MLWE is provably at least as safe as RLWE? Also less structured, so within lattice KEMs it's the more conservative choice? One easy way to understand the fundamental flaw in this argument is to look at what the same argument says for pre-quantum discrete-log systems.
2022.01.20 13:52:54: Imagine that your discrete logarithms are using the traditional multiplicative group of an n-bit prime field F_p, as in the original DH paper. A salesman is trying to convince you that it's safer to switch to some matrix version of DH using r-by-r matrices over an n/r-bit field.
2022.01.20 13:53:27: "Matrices are guaranteed to be at least as secure as fields," the salesman tells you. "Look, here's a simple proof." The proof says that if the n/r-bit field is secure then matrices over the n/r-bit field must be secure too. But this is useless: the n/r-bit field is too small!
2022.01.20 13:53:53: "I understand your concern," the salesman says. "Look at this new proof I just received. Simple _and_ preserves size! Definitely the proof for sophisticated customers like you. This proof shows that these matrices are guaranteed to be at least as secure as fields _with n bits_."
2022.01.20 13:54:26: Say the n/r-bit field is F_q. The field F_(q^r) has about n bits. The proof says that multiplication by an element of the field F_(q^r) can be viewed as an r-by-r matrix over F_q, so if there's a security problem with matrices then there's also a security problem with F_(q^r).
2022.01.20 13:54:55: But wait a minute. You weren't using F_(q^r). You were using a prime field F_p. F_(q^r) is a special type of n-bit field, with F_q as a subfield. What happens if attackers can exploit the presence of this small field F_q to break F_(q^r), and also to break the matrix system?
2022.01.20 13:55:19: In that scenario, the proof is simply relating one weak system to another weak system. The proof relies on exactly the F_q structure that the attacker is exploiting. The salesman is using this proof to convince you to add that structure, switching away from a stronger system!
2022.01.20 13:55:41: This isn't hypothetical. Exploiting subfields is a major theme of today's discrete-log attacks. F_(q^r) is now known to be weak for many values of r, sometimes _very_ weak. Also, a 1997 paper by Menezes and Wu shows that matrices don't add any security compared to fields.
2022.01.20 13:56:12: One can see the fundamental flaw in the salesman's logic without seeing any of the attacks. The proof was portrayed as comparing the matrices to the entire class of fields with n bits, but looking at the proof shows that it compares only to specially structured fields F_(q^r).
2022.01.20 13:56:43: This example also shows how dangerous it is to measure cryptography by its success in writing down "security proofs", judging systems as less risky when they have more "security proofs". What these proofs are proving isn't security. Enabling proofs often means adding weaknesses.
2022.01.20 07:45:07: Just to spell out one way to apply https://eprint.iacr.org/2022/037 to Curve25519: take point on curve (not twist); check x squareness to see if point is 2*P; compute such a P (exercise: use generic P to avoid roots); do order-4 pairing with (1,...) and 4th-power test to see if P is 4*Q.
2022.01.20 08:37:21: The generic computer-algebra view of this is that finding a curve point Q given 8*Q is solving a low-degree system of equations in two variables. That's already ok speed (done either directly or as three halvings). Everything else is about optimizing detection of soluble cases.
2021.12.27 07:54:50, replying to "Lúcás Meier (@cronokirby)": You mean examples of being blind to this observation? For various case studies, see the "machinery of cryptographic performance advertising" subsections inside https://cr.yp.to/papers.html#competitions. For the incentive structures naturally driving this phenomenon, see Section 3.8 of that paper.
2021.12.26 16:34:02: It's impressive how clearly we cryptographers can see and communicate that strong cryptography is fast enough for basically everybody when this observation threatens research in other areas, and how blind we can be to the same observation when it threatens cryptographic research. https://twitter.com/matthew_d_green/status/1473083729505570821
2021.12.26 16:25:46: Posted new version of "Cryptographic competitions" paper: https://cr.yp.to/papers/competitions-20211226.pdf Biggest updates are in Section 2, looking at more examples of the interactions between performance and cryptographic decisions. Also a new appendix for people interested in paper-writing processes.
2021.12.18 15:24:12, replying to "caffeinum.eth @ Istanbul (@caffeinum)": Glad it was useful.
2021.12.17 21:12:45: Pleased to announce the release of software collecting experimental evidence regarding the performance of the _simplest_ S-unit attack for which one can reasonably conjecture that the attack breaks polynomial-approx-factor Ideal-SVP in subexponential time: https://s-unit.attacks.cr.yp.to/filtered.html
2021.12.17 11:20:23, replying to "Reza Azarderakhsh (@Azarderakhsh)": To make sure I understand: You're complaining about a parenthetical note in a talk on quantum cryptanalysis, a note summarizing why SIKE doesn't remove the importance of investigating CRS/CSIDH security, and your complaint is that the note doesn't cite yet another cryptosystem?
2021.12.16 18:33:16: At Indocrypt (virtually) a few days ago, gave tutorial on "Quantum cryptanalysis": https://cr.yp.to/talks.html#2021.12.12 Main topics covered: the core operations supported by quantum computers; how some fundamental quantum algorithms work; and the impact of quantum algorithms on cryptography.
2021.12.10 19:45:00: I hope the #NISTPQC results end up being safe and usable, but I'll always be horrified by the process NIST followed: e.g., involving NSA for years before mid-2020 admission; grossly mishandling patents; actively fighting against transparency + objective rules + error correction.
2021.12.10 16:34:42, replying to "Sam Jaques (@sejaques)": Sent email early Nov with a simpler question; didn't hear back. Mail filtering? Senior author (who used to work for NSA) getting approval to reply? Busy with new paper version? Eventually tweeted that question (https://twitter.com/hashbreaker/status/1459198701826547713). Decided to tweet the nesting question too.
2021.12.10 12:35:22: A paper just presented at Asiacrypt (https://www.iacr.org/cryptodb/data/paper.php?pubkey=31450) exploits another mistake in the Kyber security analysis to chop off several bits of security. Kyber's claimed security margin (1) was already very small and (2) admitted several other known speedup possibilities. Hmmm.
2021.12.10 11:31:06: Looking a bit more at https://arxiv.org/abs/2110.13352, and now skeptical about Theorem 6 (never mind the application to Corollary 7). The last proof step says 2^t amplifications each costing sqrt(N), but aren't half of these nested amplifications? How are further sqrt(N) factors avoided?
2021.11.12 17:37:35: Skeptical about Corollary 7 of https://arxiv.org/abs/2110.13352. Doesn't Theorem 6 need to assume that gamma is bounded away from 1, which in turn needs N to have a higher exponent? Might still beat other approaches but needs more careful analysis of the run time, heuristic accuracy, etc.
2021.11.03 18:17:39: "Exercises on faster isogeny computation": https://velusqrt.isogeny.org/exercises-20210911.pdf Elliptic curves appear starting with exercise 30. Originally written for and distributed as a small part of the huge "Isogeny-based cryptography school" that took place July-September 2021: https://isogenyschool2020.co.uk/
2021.11.01 21:26:18: Anyone considering lattice-based post-quantum cryptography should see this warning chart: https://ntruprime.cr.yp.to/warnings.html. Full analysis is contained in new 99-page PDF "Risks of lattice KEMs" available from the same page. Page+PDF authors: NTRU Prime Risk-Management Team.
2021.10.25 12:43:43: After five years of litigation against the European version of patent 9094189, Keltie has given up: https://register.epo.org/application?number=EP11712927&lng=en&tab=doclist Meanwhile NIST's non-transparent buyout efforts seem to have failed. But there's still hope for Kyber, founded upon refusal to learn how patent law works.
2021.10.23 21:51:11: New paper with @hyperelliptic "Non-randomness of S-unit lattices": https://cr.yp.to/papers.html#spherical This paper explains the amazingly special analytic features of S-unit lattices. These features are prerequisites for the success of S-unit attacks against Ideal-SVP, a core lattice problem.
2021.10.08 18:23:25: Released an example of NIST's efforts to discourage public analysis of post-quantum patents: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/zWxLiIAFG8c/m/zbr8OkTwBgAJ Unanswered questions include (1) why they're not telling the truth about having done this and (2) why they thought doing this was a good idea in the first place.
2021.10.02 06:24:39: Remember the Keltie litigation, on behalf of an undisclosed client, trying (and so far failing) to kill a critical lattice patent? The following 17 August 2018 document reveals that two of Keltie's tech people are from the UK NCSC (NSA's buddies at GCHQ): https://register.epo.org/application?documentId=E19DS4EY1268DSU&number=EP11712927&lng=en&npl=false
2021.09.15 20:25:04: Preliminary Rust support in #saferewrite version 20210915 from https://pqsrc.cr.yp.to. Under an hour to automatically verify that compiled sha256_200bytes/rust_sha2 (using AVX2) matches compiled C ref, much faster to automatically find the bug in sha512_300bytes/rust_sha2_097.
2021.09.09 22:32:18, replying to "azet (@a_z_e_t)": An expert's mental model says that unbroken algorithms A,B,C,D,E have chance 90%, 10%, 20%, 80%, 60% of being secure. This is incredibly useful information. You think the expert wants to be subjected to idiots years later saying "E was broken and you said it was probably safe"?
2021.09.09 22:38:34: Force the expert to publicly explain the selection of A? You won't hear the 90%; you'll hear a selection of objective praise for A, things that should have been published earlier. Say that, no, we really want to hear the percentage? You'll end up with a committee of non-experts.
2021.09.09 20:46:51, replying to "azet (@a_z_e_t)": Did you read the paragraph you're quoting? CAESAR made all this clear at the beginning: we want public analyses, and for the necessary judgment calls we have a committee of top experts. Eliminating the "committee will not comment" rule would have meant not having the top experts.
2021.09.09 20:31:40, replying to "azet (@a_z_e_t)": Every cryptographic competition has had public analyses from people who happened to be on the selection committee, and presumably this will continue, so you're suggesting distinctions that have nothing to do with the actual differences between procedures in various competitions.
2021.09.09 18:08:46, replying to "azet (@a_z_e_t)": "CAESAR selection decisions will be made on the basis of _published_ analyses. If submitters disagree with published analyses then they are expected to promptly and _publicly_ respond to those analyses." First posted "Timeline (tentative)" was _5 years_ to give time for analysis.
2021.09.09 18:23:36: There were hundreds of public messages discussing procedures: e.g., various submitters asking for more time, and followup discussions. I sent more than 500 admin messages overall. But the real content of the competition was the _public analysis of submissions_. That takes time.
2021.09.09 17:34:17, replying to "azet (@a_z_e_t)": The rules were clear from the outset. All committee communications were clearly labeled and strictly followed the rules. The claims you're making are factually incorrect no matter how often you repeat them. I also see no sign that you've read the applicable portion of the paper.
2021.09.09 17:19:51, replying to "azet (@a_z_e_t)": From https://competitions.cr.yp.to/caesar-call.html: "The submitter/submitters understand that the committee will not comment on the algorithms". Whatever misinformation you heard from some sore losers, maybe consider (1) engaging in basic fact-checking and (2) not hijacking unrelated threads? Thanks!
2021.09.09 14:17:18, replying to "mjos\dwez (@mjos_crypto)": NSA "actively engages the U.S. and foreign IT industries to covertly influence and/or overtly leverage their commercial products’ designs" to make them "exploitable". This goes far beyond military purchasing. See https://cr.yp.to/papers.html#dual-ec and Section 3.6 of https://cr.yp.to/papers.html#competitions.
2021.09.09 12:25:50, replying to "Orr Dunkelman (@CryptoOrrDun)": If you're already thinking about salsa _and_ chacha then base 8 isn't enough; you really need base 16.
2021.09.09 01:22:34: Let's review. 2016-2020: NSA doesn't admit its involvement in NISTPQC. 2020.07.22 15:03: First NSA message (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/um_1oBVCtjU/m/vhTAdxp7BgAJ). 2020.07.22 22:51: NIST announces round 3 (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/0ieuPB-b8eg/m/Cl7Ji8TpCwAJ). NSA now says: Use lattices (https://www.nsa.gov/what-we-do/cybersecurity/post-quantum-cybersecurity-resources/) and PLEASE TURN OFF ECC. https://twitter.com/mjos_crypto/status/1433443198534361101
2021.09.03 18:23:50: New #saferewrite tool from https://pqsrc.cr.yp.to quickly and automatically verifies, for a variety of critical cryptographic subroutines, that optimized constant-time code matches reference code on all inputs. Slides from announcement today at ICMC 2021: https://cr.yp.to/talks.html#2021.09.03
2021.08.29 21:25:00, replying to "Adam Langley (@agl__)": There's a better encoder presented (in Python) on page 18 of https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf. Stays inside int32, space-efficient, simple. Further advantages if you're also thinking about other applications: scales well to very long sequences, with easy parallelization and vectorization.
2021.08.20 21:03:14: Just gave a talk on algorithms getting (heuristically+experimentally) within ε of shortest nonzero vector for cyclotomic Ideal-SVP, breaking through every previously claimed lower bound. Joint work w/Eisenträger, @hyperelliptic, Rubin, Silverberg, @cvvrede https://cr.yp.to/talks.html#2021.08.20
2021.08.17 20:35:06, replying to "Martin R. Albrecht (@martinralbrecht)": Starting link from his home page was to http://www.math.leidenuniv.nl/~hwl/PUBLICATIONS/1977b/art.pdf, and then looks like http->https autocorrect kicked in.
2021.08.17 19:06:22: The proofs of "limits of Schnorr-like arguments over lattices" in https://eprint.iacr.org/2021/202 are very specific to the choice of prime-power cyclotomics. As a random example, for non-prime-power m=225, degree 120, the smallest norm in the mth cyclotomic is 1801.
2021.08.17 19:10:23: Bigger examples: m=365, degree 288, smallest norm 6571; 415, 328, 11621. Of course the failure of the proof in these cases (i.e., most cases!) doesn't imply that there are better constructions. Also, perhaps more importantly, cyclotomics raise all sorts of security concerns.
2021.08.17 19:35:51: Scientifically, it's puzzling that this paper doesn't cite https://math.leidenuniv.nl/~hwl/PUBLICATIONS/1977b/art.pdf, which considers very similar objects in formula (1.16), constructs exactly the same prime-power examples in (3.1), and includes many further constructions + proofs on this topic. @martinralbrecht
2021.08.17 19:55:47: Followup papers include, e.g., https://link.springer.com/article/10.1007%2Fs00013-006-1019-0, which describes two algorithms that, given a field, search for these sequences. One would expect that a 2021 paper on these sequences for cyclotomic fields would report what those algorithms print out for cyclotomic fields.
2021.07.17 04:21:19: Measurement mechanisms matter. Widely reported: Dutch daily cases took an amazing leap from 1000 on 1 July to 10000 on 8 July and have been around 10000 since then. Not widely reported: Testing capacity in big Dutch cities was reached around 7/8 July. See https://twitter.com/jpaternotte/status/1413047741505282050.
2021.07.07 00:22:05: Most post-quantum encryption proposals rely on a "T" transform that (1) has seen very little cryptanalysis and (2) _could_ lose ~100 bits of security. My new paper "On the looseness of FO derandomization" (https://cr.yp.to/papers.html#footloose) constructs examples where T _does_ lose security.
2021.07.07 00:25:35: These are pre-quantum examples. All available post-quantum (QROM) T proofs allow even larger security losses than the pre-quantum (ROM) T proofs, which makes the combined cryptanalytic gap + proof gap even more worrisome, but QROM analysis is outside the scope of this paper.
2021.07.07 00:32:44: Perhaps the unbroken post-quantum proposals using T are secure. Or perhaps the lack of attacks against derandomization in these proposals is simply because people haven't been looking for attacks. This is just one example of how scary the overall post-quantum attack surface is.
2021.06.16 15:08:23, replying to "Steven Galbraith (@EllipticKiwi)": Reading more I see 6.2 saying that to your knowledge "all implementations" reduce; but [20] points to libgcrypt as a counterexample. The reduction takes an extra line of code, so skipping it is the simplest thing to do---and, hey, look, another line of defense against Minerva.
2021.06.16 15:15:42: On a different note, I'm puzzled by the choice to use asymptotic formalisms that by definition don't apply to a concrete signature system such as Ed25519. Quantifying the reduction cost (1) is necessary and (2) allows the definitions and theorems to be simplified (skip lambda).
2021.06.15 22:01:30, replying to "Steven Galbraith (@EllipticKiwi)": Yes, the suggestion in Section 5.3 of https://cr.yp.to/papers.html#multischnorr ends up setting bit 255 instead. The hashing is under very different constraints: doubling the output size simplifies parts of the design, helps protect implementations (as we saw with Minerva), and doesn't cost much.
2021.06.15 22:11:57: Part of the design process is predicting software incentives and turning those into helping, rather than hurting, security. Look at, e.g., https://mailarchive.ietf.org/arch/msg/cfrg/8z3ZcujGRxFSGEBI-uE7C1tjw4c/ explaining in 2014 how 512-bit nonces protect simple non-reducing implementations against nonce timing attacks.
2021.06.14 01:46:07, replying to "Steven Galbraith (@EllipticKiwi)": Pohlig-Hellman immediately reveals the bottom 3 bits, so setting them to be nonzero wouldn't gain security, while zero gives slight simplifications+speedups in optimized software. The multi-user security questions you mention are tied to the top bits, not the bottom bits.
2021.06.14 01:49:16: If you're thinking that Pohlig-Hellman won't apply to a protocol that applies the secret only to the standard prime-order base point: Sure, but basic ECDH doesn't work that way, and being able to share as much as possible with basic ECDH is a general win for the ecosystem.
2021.06.14 01:11:17, replying to "Steven Galbraith (@EllipticKiwi)": To answer your question re key clamping: variable position of leading 1 + textbook ladder → timing leak. So X25519 and Ed25519 specs both require fixed position. Section 5.3 of https://cr.yp.to/papers.html#multischnorr suggests setting the position (compatibly!) for a tight multi-user reduction.
2021.06.11 00:56:56, replying to "Paul Crowley (@ciphergoth)": The same Dual EC post-mortem is a good source re transparency of crypto standardization. Several of the transparency principles are quoted in Section 5.1 of https://cr.yp.to/papers.html#categories, and the rest of the section covers several examples of NIST's lack of transparency in #NISTPQC.
2021.06.10 21:41:49, replying to "Paul Crowley (@ciphergoth)": Random example: NIST IR 7977 clearly states that, for a NIST "competition", winners relinquish intellectual property rights so that the winner can be used royalty-free. NISTPQC is _not_ called a "competition" and did _not_ require this. _Some_ NISTPQC submitters did it anyway.
2021.06.10 21:49:40: Many cryptanalysts were already putting a lot of time into analyzing candidates, including patented candidates, during the half year before NIST posted patent statements. That's valuable public time burned because NIST didn't want to be subjected to the rules for a "competition".
2021.06.10 21:53:59: Even after NIST posted the statements, think about the choice facing cryptanalysts: if everyone stops studying security of the patented algorithm, maybe NIST says "Wow, looks solid, let's standardize it" even if it's horrifyingly easy to break. Clear danger to the public.
2021.06.10 22:08:55: A rule of having only one winner doesn't matter, since two winners can comply with the rule by simply merging; we've seen some mergers already in NISTPQC. Rules about patents and transparency _do_ matter, and NIST doesn't want to follow them; so NISTPQC isn't a "competition".
2021.06.10 14:25:46: NIST's Dual EC post-mortem https://www.nist.gov/system/files/documents/2017/05/09/VCAT-Report-on-NIST-Cryptographic-Standards-and-Guidelines-Process.pdf stated various transparency principles. It has been clear for a year that NIST isn't following those principles. Somehow I didn't realize until now that this is also why NIST refuses to formally label #NISTPQC as a "competition".
2021.06.10 14:30:43: Running a "competition", as strongly recommended in the post-mortem, would _force_ NIST to follow various procedural rules, including general due-process rules and NIST's own declarations of how a "competition" works. So NIST repeatedly insists that NISTPQC isn't a "competition".
2021.06.10 14:36:31: Of course it _is_ a competition, and NIST people keep slipping up and calling it a competition and saying whoops-we're-not-allowed-to-call-it-that, and everybody laughs. There's also a cover story claiming, falsely, that a "competition" isn't allowed to select multiple outputs.
2021.06.10 13:51:25: "Fast verified post-quantum software, part 1: RAM subroutines" white paper, slides, and video now available: https://cr.yp.to/talks.html#2021.06.09 Sometimes it's not super-difficult to have an automated guarantee that optimized code matches the spec in all cases, not just test cases. #NISTPQC
2021.06.09 15:56:10: "NTRU Prime: round-3 updates" slides+video now online: https://cr.yp.to/talks.html#2021.06.08 Covers a lot of ground in 15 minutes, including exciting news regarding FPGAs, Cortex-M4, fast keygen, TLS 1.3 integration, and NTRU Prime's success in proactively reducing the attack surface. #NISTPQC
2021.06.09 14:13:10, replying to "Steven Galbraith (@EllipticKiwi)": Was fun to watch. Happy to hear about the paper being accepted.
2021.06.08 23:59:27, replying to "Mario Alessandro Barbara🌻💾✝️ (@mabbamOG)": This was in a joint DHS+NIST talk today at the Third PQC Standardization Conference. There was similarly weird please-don't-implement-post-quantum-crypto-now messaging from other people at NIST yesterday. Supposedly videos from the whole conference will be online this month.
2021.06.08 16:23:46: Coordinated bullshit from the U.S. government re post-quantum crypto: Don't roll out post-quantum crypto now even if you can, because maybe then you'll lose "time" (throughput!) later switching to something else, and we don't want to lose "time" (latency!) in protecting users.
2021.06.07 00:37:20, replying to "Andre Esser (@4ndre3sser)": The abstract claims that non-quantum 0.292 is optimal "within a broad class of lattice sieving algorithms covering almost all approaches to date" and that "similar conditional optimality results" apply to the 0.265 "complexity for quantum sieving". Seems rather likely to deceive.
2021.06.08 00:07:44: The optimality talk today addressed this issue. The talk didn't challenge the new 0.257 improvement. Instead it seemed to say that the optimality result was for all-pairs algorithms and the 0.257 result isn't an all-pairs algorithm; ergo, no contradiction between the results.
2021.06.02 16:50:54: April 2021 posting: https://eprint.iacr.org/2021/570 says it improves lattice attack exponent 0.265 to 0.257. June 2021 posting, dated April 2021: https://web.archive.org/web/20210602144947/https://csrc.nist.gov/CSRC/media/Events/third-pqc-standardization-conference/documents/accepted-papers/kirshanova-lower-bounds-pqc2021.pdf says 0.265 can't be improved for these algorithms. Sounds like at least one of these teams has some explaining to do.
2021.06.01 12:00:51, replying to "Carl T. Bergstrom (@CT_Bergstrom)": With all due respect, it's time to call bullshit! An honest confession wouldn't hide behind statistical jargon. It would say "At the outset, I wanted to believe that COVID was no more transmissible than flu. So I believed it, and for months overconfidently ignored contrary data."
2021.05.17 12:19:26, replying to "Aram Harrow (@quantum_aram)": Top of thread: "you're deceiving people into giving you money. That's unethical." I agree with you that this ethics problem would disappear if the deception disappeared. I don't agree with your claim that it's "a term with a simple clear technical meaning" and thus not deceptive.
2021.05.17 12:29:18: The words "quantum" and "supremacy" have preexisting meanings, setting up a preexisting understanding of "quantum supremacy". This understanding doesn't match the Humpty Dumpty redefinition. You're also incorrect in saying this wasn't addressed already: https://twitter.com/hashbreaker/status/1391472063483813888
2021.05.15 22:01:33, replying to "Aram Harrow (@quantum_aram)": You dispute @preskill admitting his "quantum supremacy" term "exacerbates the already overhyped reporting on the status of quantum technology". You claim the term isn't deceptive. Why should it be impossible to say what sort of evidence would convince you that it _is_ deceptive?
2021.05.15 21:47:05: Looks like it's time for a new burst of papers from cryptographers analyzing how privacy-preserving contact-tracing systems can be extended to recognize that you were in a room from 11:00 to 11:30 and someone infected was in that room from 10:15 to 10:45. https://www.wired.com/story/the-teeny-tiny-scientific-screwup-that-helped-covid-kill/
2021.05.15 20:31:01, replying to "Aram Harrow (@quantum_aram)": Thanks for the clarification. What level of evidence would convince you that the word "supremacy" is making politicians throw more money at quantum technology than they would otherwise? (Maybe I should emphasize that "distorting everything" is setting the deception bar too high.)
2021.05.15 16:58:02, replying to "Aram Harrow (@quantum_aram)": Still having trouble figuring out whether you're disputing @preskill admitting that his "quantum supremacy" term "exacerbates the already overhyped reporting on the status of quantum technology". It's hard to see how you can claim the term isn't deceptive without addressing this.
2021.05.15 15:16:10, replying to "Aram Harrow (@quantum_aram)": Clarification question: Are you disputing @preskill's admission that "the word exacerbates the already overhyped reporting on the status of quantum technology"? Or are you claiming that there's no ethical problem with deception unless it's shown to have "significant" influence?
2021.05.15 08:12:58, replying to "Aram Harrow (@quantum_aram)": Reality check: @preskill admitted (1) "the word exacerbates the already overhyped reporting on the status of quantum technology"; (2) he "anticipated" this when he introduced the "quantum supremacy" term. This word choice deceives people, including politicians funding the area.
2021.05.15 08:21:45: Feigning ignorance of the deception---or saying "How could we possibly talk about a quantum-circuit demo except as quantum supremacy? Quantum dominance has two different definitions in the literature, and quantum superiority has three!"---doesn't make the ethical issue go away.
2021.05.13 15:34:13: New paper "CTIDH: faster constant-time CSIDH", https://ctidh.isogeny.org: fully interoperable, new space of private keys, new algorithm, almost 2x speedup. Authors: @gustavosbanegas, @hashbreaker, @primaboinca, @tungchou1, @hyperelliptic, @mchl_myr, Smith, @jsotakova.
2021.05.13 11:16:45, replying to "Probabilita (@kora@chaos.social) (@dakoraa)": China ran its own PQC standardization effort. I advised against participation: spreading cryptanalytic resources creates its own risks. On the other hand, a standards-development organization picking a subset of NISTPQC candidates, no new submissions, wouldn't trigger such risks.
2021.05.13 07:26:00: NIST is fighting FOIA requests re efforts to buy out post-quantum patents. Eventually admits efforts for 9094189 vs Kyber+SABER (Jan: "mostly waiting for them to give us a number"). Claims no discussions for 9246675 (which reportedly killed Google's NewHope experiment) and ISARA.
2021.05.13 07:38:59: ISARA public email mid-2019: "We will work with NIST"; "Discussions started Friday". FOIA request 2020.12 asked for list of all patents that NIST has learned about re NISTPQC, and dates of all communications with patent holders. NIST response 2021.05 mentions zero ISARA patents.
2021.05.13 07:58:07: Recall that litigation by British law firm Keltie, on behalf of a secret client, so far totally failed to kill European version of 9094189. A hearing on their appeal is scheduled for 2021.11: https://register.epo.org/application?number=EP11712927&lng=en&tab=doclist NIST says it's making NISTPQC standardization decisions in 2021.
2021.05.12 15:39:49: It's clarifying to look at cryptography from the attacker's perspective. See, for example, NSA's internal documents on crypto standardization: "Narrowing the encryption problem to a single, influential algorithm might drive out competitors, and that would reduce the field..." 1/2
2021.05.12 15:40:22: "... that NSA had to be concerned about. Could a public encryption standard be made secure enough to protect against everything but a massive brute force attack, but weak enough to still permit an attack of some nature using very sophisticated (and expensive) techniques?" 2/2
2021.05.09 21:14:40: Scientists: Please stop using and condoning the phrase "quantum supremacy", even if you're confident that it has a clear definition and is a useful milestone and isn't confused with white supremacy. Why? Because you're deceiving people into giving you money. That's unethical.
2021.05.09 21:16:06: Insisting you're free to redefine "quantum supremacy" to mean just what you choose it to mean is like insisting that you're free to redefine "Bourne supremacy" to refer to Matt Damon's scenes in Team America: World Police. https://www.youtube.com/watch?v=gnPWJOJYVKc Sorry, no, that isn't supremacy.
2021.05.09 21:16:07: "Funding decisions are made by experts who know the meaning and aren't influenced by the wording choices!" --- Bullshit. The politicians being convinced to pour billions into quantum technology are not experts. (Also note that experts aren't magically immune to unconscious bias.)
2021.05.04 19:05:10, replying to "Luca De Feo (@luca_defeo)": "Nowhere in Section 5 does Craig speak of competitors": Huh? Section 5's summary claims that SIKE has a "good head start" and that "protecting it in most scenarios would be relatively cheap". The actual content of 5 doesn't justify this summary, and doesn't make a case for SIKE.
2021.05.04 15:15:58, replying to "Luca De Feo (@luca_defeo)": Every cryptosystem X can claim _some_ applicability of existing techniques for side-channel protection. Should each X publish this as part of a "Case for X", leaping to the conclusion that it's cheaper/easier to protect than its competitors? Sorry, no. Needs quantified analysis.
2021.05.04 15:37:38: Analogy: "This chaos-based RNG uses multiplications, and there has been a lot of work on multiplication speed, so obviously this RNG will be faster than non-mult RNGs once we've written software. Also, obviously the software will pass whatever statistical tests you can imagine."
2021.05.04 14:58:41, replying to "Luca De Feo (@luca_defeo)": Combining hashed DH with a cipher is an extra source of complexity, certainly, and is another example where a lot of work has gone into improving robustness. For example, zero-padding and then applying a wide-block cipher _doesn't_ have the same fragility as a MAC equality test.
2021.05.04 06:56:37, replying to "Luca De Feo (@luca_defeo)": The crazy leap from "DH is secure" to "every protocol is secure" certainly causes real-world failures. This doesn't mean there's anything controversial about the security of DH. It also doesn't at all support the claim of SIKE's extra complications being easy/cheap to protect.
2021.05.04 07:06:27: As for proofs, https://eprint.iacr.org/1999/007 proves (pre-quantum) DH CCA security under a standard-model assumption that has resisted extensive cryptanalysis for typical curves and hash functions. Saying the assumption follows from DDH in the ROM is wildly understating how solid it is.
2021.05.04 07:16:34: Adding timing attacks into the picture makes ECDH security much more fragile, although doable. Adding more side channels turns it into "typical deployments are breakable at low cost". SIKE is more complicated, with more side-channel attack targets, and needs more investigation.
2021.05.04 07:26:27: Structurally, the vagueness in the middle part of "SIKE => reminiscent of ECC => cheap/easy to protect against side channels" is also problematic, since for each example of SIKE side-channel risks one then gets side-tracked into discussing the extent to which it's an ECC example.
2021.05.04 07:33:35: How expensive is it to protect SIKE against low-cost or medium-cost side channels? We don't know. Could be more expensive than for competitors; could be less. The necessary analysis is in its infancy. Trying to claim that this supports a "case for SIKE" today is unjustifiable.
2021.05.04 07:38:49: Having this flimsy side-channel argument in a "case for SIKE" document also distracts attention from arguments that are clear and quantified and justified, such as the fact that the best attack known against SIKE's proposed parameters is 1990s-vintage vOW golden-collision search.
2021.05.03 14:25:00, replying to "Luca De Feo (@luca_defeo)": CHES is consistently high quality, and half the papers are on side channels, so you can just start reading from the current year and work backwards. If time is more limited, I'd suggest starting with https://scholar.google.com/citations?user=1k_rBAkAAAAJ and, more on the defense side, https://scholar.google.com/citations?user=acvxLrIAAAAJ.
2021.05.03 13:21:44, replying to "Luca De Feo (@luca_defeo)": One of the ways ECDH has improved over the years is moving to curves+encodings where this KEM (and, more broadly, ECDH NIKE) is secure _without_ any checks for invalid points. Also, hashed DH doesn't need a gap assumption except for writing theory papers. Pairings don't break it.
2021.05.03 13:04:02, replying to "Luca De Feo (@luca_defeo)": Um, two decades of CHES papers?
2021.05.03 10:31:08, replying to "Luca De Feo (@luca_defeo)": Here's a KEM: Alice's public key is aG. Bob sends random bG as the ciphertext. The session key is a hash of (aG,bG,abG). SIKE is much more complicated than this, and has many more side-channel targets, such as the comparisons in the FO transform used to protect against GPST.
2021.05.03 10:44:38: We've seen again and again, for a wide range of cryptographic functions, that implementations without expensive countermeasures are broken at low cost by physical side channels beyond timing. There are many papers quantifying this. Unquantified security claims lack credibility.
2021.05.02 19:07:11, replying to "Luca De Feo (@luca_defeo)": The SIKE implementation CCA disaster, from trying to stop FO timing attacks, is a perfect example of why protecting SIKE (1) isn't easy and (2) isn't like ECC. People also keep publishing papers on ECC side-channel attacks. "Not many SIKE papers ergo secure" is a flimsy argument.
2021.05.02 08:47:12, replying to "Luca De Feo (@luca_defeo)": The official SIKE code screwed up constant-time comparisons, allowing a CCA attack in December. Defending against more invasive side channels is harder. The necessary security analysis has barely started. The broader literature is full of breaks of overconfident security claims.
2021.05.01 09:48:32, replying to "Luca De Feo (@luca_defeo)": 5 spends all its time describing some SIKE side-channel countermeasures. How is this supposed to justify the main 5 conclusion, namely that SIKE is easier/cheaper to protect than competitors? Weak, unquantified arguments for SIKE => like ECC => easy; zero analysis of competitors.
2021.04.29 16:44:02: Agreeing with main points in 3, 4, 6, 10 in https://eprint.iacr.org/2021/543. More objections to 2, 5, 7, 9. Most important dispute is regarding risk management, 1+8. Recent advances in torsion-point attacks have killed a huge part of the SIKE parameter space, far worse than MOV vs ECDLP.
2021.04.29 16:57:33: The "failure" comments inside 9 are a smaller-scale risk-management issue. Here the paper is correct in saying that decryption failures increase the post-quantum attack surface, but is wrong in claiming that SIKE is the only #NISTPQC encryption option without decryption failures.
2021.04.26 15:18:19, replying to "the other Tom (@uberbaud)": I think @WhiteHouse is selling this wrong. Instead of saying "These vaccines going to Mexico aren't taken away from Americans" they should say "We're taking half of the vaccines away from Wyoming and sending them to Mexico since people in Wyoming are leaving them on the shelves."
2021.04.25 22:54:43: Apparently some Americans aren't making vaccination appointments despite being eligible. Will they be jealous if and when we start publicly sending spare vaccines to Mexico, Brazil, India, etc.? "I didn't want this dose but I definitely don't want those _foreigners_ to have it!"
2021.03.21 06:17:26, replying to "Аlекsеi Udovenko (@hellman1908)": Indeed, testing w^((n-1)/2) where w has Jacobi symbol -1 isn't much slower than the strong-probable-prime test; but it's more work to implement and has a different analysis. The question is whether the strong-probable-prime test should be credited to Artjuhov, or to Selfridge.
2021.03.20 08:40:52: Request for math-history help from readers fluent in Russian: strong-probable-prime tests (see https://en.wikipedia.org/wiki/Probable_prime) are sometimes credited to Artjuhov (http://matwbn.icm.edu.pl/ksiazki/aa/aa12/aa12125.pdf) but the closest I've found there (middle of page 363) needs Jacobi symbols. Am I missing something?
2021.02.20 11:21:38: Hundreds of well-known cryptographers signed a statement https://drive.google.com/file/d/1OQg2dxPu-x-RZzETlpV3lFa259Nrpk1J/view in April 2020 advocating "the most privacy-preserving option" and data minimization regarding contact tracing. Are mass-surveillance programs a factor in @IACR_News decisions on conference locations?
2021.02.14 13:28:30, replying to "Boaz Barak (@boazbaraktcs)": The literature on SAT challenge problems focuses on the edge of what a general-purpose SAT solver can handle on an academic's computer. This is quantitatively (and, I would expect, qualitatively) very different from the edge of what cryptanalysts can break using serious hardware.
2021.02.11 07:53:05: Guess for where the 20000 comes from: (1) X falls for D-Wave's BS that n-qubit quantum computers will magically minimize any n-variable quadratic, in particular breaking n-variable SAT. (2) X "discovers" well-known conversion of typical cipher into SAT with about 20000 variables.
2021.02.11 08:16:58: It's easy to see how #2 turns into a press release if X is a snake-oil salesman, but I think the bigger problem is D-Wave's BS. Can we agree on some "Has D-Wave solved these yet?" challenge problems? What's the strongest cipher that we can express quadratically in n variables?
2021.01.31 18:40:10: Our inversion code is now generalized to handle common 256-bit primes at almost the same speed as 2^255-19, around 4000 Skylake cycles: https://gcd.cr.yp.to/software.html Still haven't fully verified, so don't put into production. Tracking verification progress: https://gcd.cr.yp.to/verif.html
2021.01.18 21:03:51: A long time ago, August 2019, the CHES conference was in Atlanta (changing venue at the last moment to the Westin because the Sheraton had a Legionnaires outbreak, which seemed terrifying at the time). Conference outing was to MLK National Historical Park: https://en.wikipedia.org/wiki/Martin_Luther_King_Jr._National_Historical_Park
2021.01.13 14:18:03: Digression into computational geometry: The Freeman--Millman--Snoeyink integer-hull algorithm https://web.archive.org/web/20170705095627/https://www.cs.bgu.ac.il/~eurocg14/papers/paper_58.pdf does not work correctly. For example, input (-4,2), (5/2,-1), (-2,5) fails to include (-2,5) in output; the algorithm makes wrong decisions after finding (1,1).
2021.01.10 13:46:52, replying to "darix (@darixzen)": It's slightly over 5000 on the 1st-generation Zen microarchitecture; see the "rumba7" note on the web page. Was expecting to pick up some newer Zen boxes (faster AVX etc.) for cryptographic benchmarking during 2020, but there were many ways that 2020 didn't exactly go as planned.
2021.01.10 13:36:43: Now under 3900 Skylake cycles for code that seems to compute inverses mod 2^255-19: https://gcd.cr.yp.to/software.html This is further work with @bo_yin, also using ideas from Greg Maxwell and @pwuille. Still exploring speeds, still haven't verified the code, so don't put into production.
2021.01.08 16:21:05, replying to "Kevin McCurley (@mccurley)": The comment and the picture seem appropriate, but doesn't RWC 2021 last until the 14th instead of the 13th? Is this a subtle allusion to how tiny-sounding mistakes in cryptography can snowball into having much larger effects? Or you're saying you don't like the talks on the 14th?
2021.01.04 16:57:51, replying to "Peter Todd (@peterktodd)": Random examples from Taiwan: https://www.cdc.gov.tw/En/Bulletin/Detail/OYA5JuINJwUU90QHA6I67w?typeid=158 from February 2020 says "Taiwan identifies source of infection for 19th case"; https://www.cdc.gov.tw/En/Bulletin/Detail/tlyAMFhAVSCMoCyT_A8ISg?typeid=158 from April 2020 says "The CECC continues to investigate related contacts of the case to identify the source of infection".
2021.01.04 15:45:13: Featured in today's edition of "See how country X is _not_ doing what the successful countries are doing": https://www.citizensinformation.ie/en/health/covid19/contact_tracing.html says that X traces contacts of an infected person P back 48 hours. Maybe finds infections caused by P, but won't find the moment that P was infected.
2021.01.01 09:03:59, replying to "Luke Champine (@lukechampine)": Signing with many precomputed points can easily spend 30% or more of the mults on Fermat inversion, and then the question is how well mults are implemented vs state-of-the-art asm. But note that if you're bottlenecked by signing then you can batch inversions (Montgomery's trick).
2020.12.31 18:35:00, replying to "Mark D (@MarkDCali)": Fixed, thanks.
2020.12.31 13:55:52, replying to "Abraham D. Smith (@abrahamdsmith)": The code has passed many billions of tests, but this doesn't rule out the possibility of wrong results for some inputs. (Low-cost protection: multiply 1/x by x; if result isn't 1, try again with random xr.) Verification would analyze what the code does for all possible inputs.
2020.12.31 14:06:49: It's clear from the relevant literature how to write down a computer-verified proof of correctness of inversion code along these lines, assuming the machine instructions work as documented, but the situation today is that a proof hasn't been written down for this particular code.
2020.12.31 14:14:15: Example of the importance of verifying gcd/inversion code: https://www.forbes.com/sites/daveywinder/2019/06/12/warning-windows-10-crypto-vulnerability-outed-by-google-researcher-before-microsoft-can-fix-it/ Our new code doesn't have data-dependent branches, so it won't hang on some inputs the way Microsoft's code did, but one also doesn't want to have to analyze the security impact of wrong outputs.
2020.12.31 13:24:52: Not verified yet, so don't put into production, but seems to compute inverses mod 2^255-19 in under 4800 Skylake cycles: https://gcd.cr.yp.to/software.html Also speed records on Haswell, Broadwell, Kaby Lake, etc. Joint work with Bo-Yin Yang. Uses convex-hull calculations from @pwuille.
2020.12.28 15:56:21, replying to "JP Aumasson (@veorq)": iDASH won for the example of more advanced competitions, since it has been going for several years. (Had to decide on rules for how competitions were competing with each other!) Obviously the paper focuses on the most basic cryptographic primitives, starting with block ciphers.
2020.12.26 18:09:32, replying to "Probabilita (@kora@chaos.social) (@dakoraa)": Storing data encrypted and authenticated on an untrusted device (external memory, servers, ...) tends to get around space limits, yes, while raising the question of how much time is consumed by the symmetric crypto + communication. Not what public-key cryptographers want to hear.
2020.12.25 07:41:52: New paper "Cryptographic competitions": https://cr.yp.to/papers.html#competitions This paper surveys procedures that have been used in cryptographic competitions, and analyzes the extent to which those procedures reduce security risks. #DES #AES #eSTREAM #SHA3 #CAESAR #NISTPQC #NISTLWC #NSA
2020.12.20 19:42:22: As followup to an email discussion, looking for the history of "Stuff a signature on a message into a URL added to the message so users don't complain that they're seeing signatures". Also variants such as including a key, including a key hash, having the URL usefully clickable.
2020.12.19 07:15:36, replying to "Peter Todd (@peterktodd)": From the outset, compared to the successful countries, Canada has not been doing as much to fight COVID. It did enough to eventually get R below 1, but then relaxed in the summer (e.g. starting in July to drop quarantine requirements for travelers) instead of finishing the job.
2020.12.19 07:31:26: The U.S. reaction has been even less competent but is pervasively marketed in the U.S. as being the best it could possibly have been. Typical excuses for not reporting what successful countries did: "we can't afford that"; "that wouldn't have helped"; "those countries are lying".
2020.12.18 18:27:12, replying to "Peter Todd (@peterktodd)": Some T-cell cross-reactivity exists, but calling this "immunity" is deceptive; see https://www.nature.com/articles/s41577-020-00460-4. The UK's failure to eradicate COVID is the result of human choices; see, e.g., https://www.nytimes.com/2020/08/14/opinion/coronavirus-europe-vacation.html. Yes, humans are influenced by the weather, and use it as an excuse.
2020.12.18 17:34:55, replying to "Peter Todd (@peterktodd)": The study reported 5% (minus false positives) IgM seroprevalence _in Thai hospitals_ in April/May/June. This doesn't contradict the whole-population statistics; it simply illustrates one of the reasons that health-care workers around the world are a high priority for vaccination.
2020.12.18 17:03:13, replying to "Peter Todd (@peterktodd)": The Canadian government was already claiming to be doing "very rigorous contact tracing" in late March, and it simply wasn't true: https://nationalpost.com/health/covid-19-it-worked-in-asia-the-who-says-its-crucial-but-is-canada-still-using-contact-tracing Meanwhile they were screwing up most of the toolbox: e.g., actively discouraging mask use. Must be the weather's fault, eh?
2020.12.17 05:35:25, replying to "Peter Todd (@peterktodd)": You keep focusing on lockdowns, but most countries setting the goal at eradication have limited the use of lockdowns and have deployed a large toolbox of better-bang-for-the-buck techniques to successfully keep R down. For Thailand's testing strategy, see https://ddc.moph.go.th/viralpneumonia/eng/file/guidelines/g_surveillance_150520.pdf.
2020.12.17 06:07:36: For typical American (and Canadian and so on) readers it's educational to study this document, which spells out tons of sensible things that were already in Thailand's testing strategy early in 2020, and it's embarrassing to see that the U.S. couldn't manage most of these things.
2020.12.16 14:42:53, replying to "Peter Todd (@peterktodd)": Smallpox was a highly contagious respiratory disease, everywhere on the globe. It was eradicated through testing, tracing, quarantines, and vaccines. As for COVID-19, the countries that eradicated it pre-vaccine have thriving economies now and are re-opening travel to each other.
2020.12.16 14:18:22, replying to "Peter Todd (@peterktodd)": Thailand is a country of 70 million people with only 60 COVID-19 deaths, almost entirely in March-May. They aren't flying blind: 1000 sensibly deployed tests per day. The lockdown was done in several weeks, while many other helpful actions continued to limit spread of the virus.
2020.12.16 04:30:34: In Peikert's fantasy world, courts are "likely" to declare that patents https://patents.google.com/patent/WO2011101598A1/en + https://patents.google.com/patent/WO2013152725A1/en are "obvious", so it's "misinformation" to say these threaten Kyber. In reality, patent 1 has already survived a round of litigation: https://register.epo.org/application?number=EP11712927&lng=en&tab=doclist
2020.12.14 13:43:22, replying to "Peter Todd (@peterktodd)": Europe isn't a monolith, but on average was taking more steps than the U.S. in the spring, successfully driving COVID numbers way down, and then stupidly relaxing instead of finishing the job. Plus, yes, refusing to acknowledge and study and imitate what successful countries did.
2020.12.14 13:33:08, replying to "Peter Todd (@peterktodd)": I also listed Thailand, which last I checked isn't an island, but let's play along and focus on islands. In your human-choices-don't-matter model of COVID-19's island spread, how exactly do you explain Hawaii doing so much worse than Australia, New Zealand, Singapore, and Taiwan?
2020.12.12 07:38:44, replying to "Peter Todd (@peterktodd)": You mean, beyond the Australian example that I mentioned, and other examples leaping out from the page that I cited such as New Zealand, Singapore, and Thailand? The one that I'd recommend studying is Taiwan, where the March list of action items is simply amazing to read through.
2020.12.12 07:44:56: Perhaps some people looking at the graphs will say "Taiwan has had _hundreds_ of cases in the past six months! That's not eradication!" Travelers arriving in Taiwan are quarantined for two weeks, and of course sometimes turn out to be positive, which is counted as a Taiwan case.
2020.12.11 16:36:07, replying to "Peter Todd (@peterktodd)": I gave details of the Australian example, and pointed to a page whose graphs make it easy to see more examples. _Temporary_ reduction of virus prevalence isn't enough; that's exactly the point! The successful countries set the target at eradication, and don't let up until then.
2020.12.10 04:44:03, replying to "Peter Todd (@peterktodd)": Apply enough tools to move R to, say, 0.5; serious lockdowns can do this by themselves, but combining several lower-cost tools is smarter. Case numbers go down. Then: (1) Idiotically declare mission accomplished. Or: (2) Keep applying the same tools until the virus disappears.
2020.12.10 05:06:12: Some of the basic tools for reducing R, such as testing and tracing and quarantines, become _even more effective_ as case numbers drop (because resources are allocated better), so keeping R far below 1 becomes easier and easier as the weeks go by, and then the virus is gone.
2020.12.10 05:21:16: A properly designed control system looks like this: "Consistently test. Aim for the positives each week to be below half of what they were the previous week. If they aren't, ramp up interventions until we've caught up." It doesn't look like this: "Aim for 3% positives each week."
2020.12.09 18:50:44, replying to "Peter Todd (@peterktodd)": Hmmm, not sure what the word "many" is doing here. For me what's important is that we've seen country after country successfully following the same eradication strategy: set the target at 0 and use masks, closures, testing, tracing, quarantines, etc. until the target is reached.
2020.12.09 18:59:45: The U.S. has repeatedly demonstrated the ability to reduce cases (and hospital strain and deaths). However, the measures taken are half-hearted and released too soon, so cases go back up again. The core problem is that the feedback system isn't setting zero cases as the target.
2020.12.09 17:38:18, replying to "Peter Todd (@peterktodd)": Hawaii is an island state with good weather, has about 6% the population of Australia, and has had 600 cases in the past week. How exactly is Hawaii "doing much more than Australia"? Doesn't Hawaii allow anyone to take a NAAT test, fly to Hawaii 3 days later, and skip quarantine?
2020.12.09 16:56:58, replying to "Peter Todd (@peterktodd)": For example, https://www.health.gov.au/news/health-alerts/novel-coronavirus-2019-ncov-health-alert/coronavirus-covid-19-current-situation-and-case-numbers reports that Australia over the past week has 1 local case, under investigation, and 69 quarantined-traveler cases. (25M population. 10M tests in 2020.) A good starting point to get the big picture of many countries is https://www.endcoronavirus.org/countries.
2020.12.09 14:07:49: TCP (without BBR etc.) constantly accelerates communication, straining buffers, until news of packet drops triggers temporary deceleration. The U.S. handles COVID-19 by constantly accelerating interaction, straining hospitals, until news of deaths triggers temporary deceleration.
2020.12.09 14:13:25: What happens when some TCP connections stop loading the network? The remaining connections speed up to keep straining buffers. Packets drop. When some people are vaccinated against COVID-19, will the U.S. respond by accelerating interaction to maintain hospital strain and deaths?
2020.12.09 14:35:46: BBR reacts faster to problems. It aims, with high success, for zero strain on buffers and zero dropped packets. It can use the network even better than alternatives. One country after another has successfully eradicated COVID-19 cases; the U.S. reacts with ignorance and denial.
2020.12.07 05:34:53, replying to "Paul Wouters (@letoams)": Re "Can you please quote the first sentence that you're disputing" you say "The line in question would be 'The intern used a mouse to select the original 3 on the screen, then typed 4,'" Then re "you denied the first-hand report in my blog post" you say "I didn't deny it." Huh?
2020.12.06 21:30:05, replying to "Chris Jefferson (@Azumanga)": Example of a talk where I shredded a paper (DMR) that promoted a cryptosystem (McEliece) that I've put lots of work into: https://cr.yp.to/talks/2011.09.22/slides.pdf As for KN, the experiment seems to have been conducted properly, but the authors then massively misrepresented what they had measured.
2020.12.06 21:13:07, replying to "Ric “el pony esponjoso” (@fluffypony)": Can you elaborate on what's bothering you about the example? For me the shocking level of observed inefficiency is the critical point. This leads into the broader question of what inefficiencies there are in the process, how tools influence this, how we can measure this, etc.
2020.12.06 20:51:15, replying to "Paul Wouters (@letoams)": Not a student of mine, and not what my blog post says. You appear grossly misinformed regarding the level of experience of typical users; on this absurd basis you denied the first-hand report in my blog post; rather than admit error and learn something, you now add random noise.
2020.12.06 20:24:17, replying to "Luca De Feo (@luca_defeo)": The metric for a tool is how efficient document preparation is. The behavior of real users, mostly non-experts, is part of this. Document revisions are part of this. If a tool's UI pushes users into suffering through painful revisions, it's the tool's fault, not the users' fault.
2020.12.06 18:53:09, replying to "Paul Wouters (@letoams)": The sentence is a first-hand report of my observations of what the interns were doing. You're in denial of the report. Your argument for this denial is that the report implies that the interns had "a fundamental lack" of "basic word processing knowledge". Did I get that straight?
2020.12.06 19:05:37: I guess next you'll claim that questions like https://answers.microsoft.com/en-us/msoffice/forum/msoffice_word-mso_win10-mso_o365b/how-to-change-indentation-of-numbered-heading/765aeec2-991e-476f-a13c-3cf647195135 were faked by the Chinese to make Word look bad, since clearly no real user could have such a "fundamental lack" of "basic word processing knowledge". Why blame the users when we can deny that the users exist?
2020.12.06 18:40:23, replying to "Brian Smith (@BRIAN_____)": You've suggested multiple times now that you've identified some sort of error in the blog post. Can you please quote the first sentence that you're disputing, and say why you don't think the sentence is correct?
2020.12.06 18:27:51, replying to "Ric “el pony esponjoso” (@fluffypony)": Or maybe they had no idea how to auto-number within the format of that document (non-indented numbered paragraphs), or how to auto-number anything. I didn't ask. Anyway, I'm missing how these assessments of intern competence are supposed to be disputing something in my blog post.
2020.12.06 18:14:22, replying to "Brian Smith (@BRIAN_____)": Not sure what you're claiming is wrong in the intro. The interns were handling a list renumbering in exactly the horrifying way that the intro reports.
2020.12.06 17:50:08, replying to "Wouter (@Wouter_jo)": I covered this in the blog post: "Microsoft Word isn't completely missing abstractions, but these abstractions are competing for user-interface resources against features encouraging the user to work at lower abstraction layers ... pushing users into doing something simpler" etc.
2020.12.06 18:03:51: The most obvious aspect of this competition is the user-interface decision to emphasize what the document currently looks like. The user ends up almost completely blind to abstractions that are planning for revisions of the document. LaTeX does a much better job of showing those.
2020.12.06 17:12:44: New blog post "Optimizing for the wrong metric, part 1: Microsoft Word": https://blog.cr.yp.to/20201206-msword.html This is a review of "An Efficiency Comparison of Document Preparation Systems Used in Academic Research and Development" by Knauff and Nejasmic. #latex #word #efficiency #metrics
2020.12.01 10:48:14, replying to "Stefano Tessaro (@StefanoMTessaro)": If I try to use HILL defn 3.1.1 to evaluate the NIST P-256 security level, I get "syntax error". If I charitably extend the syntax, I can get anything between 0 and 2^85, depending on interpretation of various undefined terms. Giving definitions that match reality isn't so easy.
2020.11.21 17:25:34: "Each sensor sold in this state, whether or not included in a larger device, must have its own easily usable hardware switch to remove power, and its own clearly visible LED displaying red whenever there is power. Sensors include but are not limited to microphones and cameras."
2020.11.14 06:10:22, replying to "Pedro Maat C. Massolino (@pmaat)": Can do at least 2x better than this by swapping in the (fully implemented) integer multipliers from https://quantum.isogeny.org, which are just 78828 ANDs for 255-bit multiplication, or 46355 ANDs for 255-bit squaring. Bit operations for even fancier multipliers can do even better.
2020.11.09 16:24:38: I must admit to being even more puzzled by the confident early calls (for R) of the Senate race in Maine than the confident early calls (for D) of the presidential race in Arizona. Are there any scientific studies of the error rates of various mechanisms used to make these calls?
2020.10.31 16:28:07: NTRU Prime web page https://ntruprime.cr.yp.to now updated for round-3 NISTPQC submission, expanded team, new FAQ, expanded warnings regarding lattice security risks, etc. Recommended sntrup761 and all other round-2 parameter sets are fully interoperable with their round-3 versions.
2020.10.30 15:55:01: People who trust optimizing compilers to work correctly seem to be surprised by a 2020 gcc bug report https://gcc.gnu.org/pipermail/gcc-bugs/2020-May/702175.html where the optimizer treats byte arrays as equal if they pass strcmp. For comparison, here's a gcc bug report I filed last century: https://gcc.gnu.org/pipermail/gcc-bugs/1999-December/031165.html
2020.10.29 16:45:46: If someone is worried that hashcash drops from pre-quantum security 2^n to post-quantum security 2^(n/2), why address this with lattices as in https://eprint.iacr.org/2020/1362 rather than symmetric techniques? Search for, e.g., 2n-bit hash collisions, and rely on https://cr.yp.to/papers.html#collisioncost.
2020.10.29 17:18:04: There are many other applicable symmetric techniques: e.g., typical password-hashing functions will be super-expensive to compute reversibly. Lattices create unnecessary security risks and in any case make the security analysis vastly more complicated. What's the claimed benefit?
2020.09.25 11:16:50: NIST often spreads the misconception that it's required by law to take secret input from NSA. The law tries to improve information security and avoid redundant effort by requiring NIST to consult with NSA (see https://www.law.cornell.edu/uscode/text/15/278g-3) but never requires _secret_ consultations.
2020.09.25 07:13:55: 2016 blog post where I proposed eliminating the #NISTPQC categories in favor of "a two-dimensional plot of speed vs. security level": https://blog.cr.yp.to/20161030-pqnist.html I focused on avoiding innocent errors, but this would also have stopped discretization attacks: it's the strong defense.
2020.09.23 20:02:16, replying to "James Howe (@JamesHowe1729)": The reference implementation of NTRU Prime (see https://ntruprime.cr.yp.to/software.html) is in Sage (https://sagemath.org), which is Python plus a bunch of math libraries. Python, Sage, etc. aren't safe against timing attacks, but are good for readable implementations to compare to the specs.
2020.09.21 19:02:02, replying to "Mark C. (@LargeCardinal)": The gerrymandering analogy is interesting. True democracy (no divisions) would be the strong defense. I think the gerrymandering attacker has to do much more guessing regarding which divisions will work well, but has the advantage of not having to make the divisions look natural.
2020.09.18 06:24:52: New paper "A discretization attack": https://cr.yp.to/papers.html#categories Identifies another NSA-exploitable weakness in standardization processes. Includes a detailed case study of how #NISTPQC could hypothetically have been attacked, and evidence suggesting that it was in fact attacked.
2020.09.02 13:52:33: NIST invited selected people to attend a talk a few days ago in which NIST shifted its rationales for which post-quantum systems to push in #NISTPQC: https://www.scribd.com/document/474476570/PQC-Overview-Aug-2020-NIST See how many differences you can spot from the originally stated rationales: https://doi.org/10.6028/NIST.IR.8309
2020.08.03 15:21:22: New paper "BasicBlocker: Redesigning ISAs to Eliminate Speculative-Execution Attacks" online from @sec_janthoma, Jakob Feldtkeller, Markus Krausz, Tim Güneysu, and me: https://arxiv.org/abs/2007.15919 Speculative execution is much less important for performance than commonly believed.
2020.08.02 20:07:17, replying to "฿itcoin (@CryptoChrisG)": In the Sea of Cryptography, the top of the food chain is a very dangerous type of shark called the Cryptanalysts. Many of these sharks are too deep for us to see, but now one of them has leapt out of the water and bitten in half a blind man standing at the Schnorr. Um, the shore.
2020.07.30 18:20:31, replying to "Andrea Basso (@andreavbasso)": The "doctrine of equivalents" automatically extends claims beyond their literal meaning. The specification says x^n-1 is just an example; I don't see how U.S. courts would allow x^n+1 to evade the patent. Also, the polynomial isn't explicit in the European version of the claim.
2020.07.30 09:03:46, replying to "Diego F. Aranha 🕷️ (@dfaranha)": When NIST was first proposing low-security (512-bit) DSA as a standard, it took a lawsuit by CPSR to reveal NSA's involvement: https://epic.org/crypto/dss/new_nist_nsa_revelations.html The existence of NIST-NSA coordination for #NISTPQC can't be a scandal if it's revealed _by NSA_, right? Maybe not a bad PR move.
2020.07.30 09:14:38: Next I suppose NIST will spin a story about how the law _forces_ it to take private input from NSA (not true: if NIST were serious about transparency then it would automatically and immediately publish all of its NSA communication), and how they value NSA's technical expertise.
2020.07.30 09:19:05: NSA's classified documents showed that its goals for DES standardization were for DES to be (1) "weak enough" for NSA to break and (2) "influential" enough to "drive out competitors". Meanwhile NSA waged a multi-decade PR battle to try to convince people they were the good guys.
2020.07.30 07:09:21, replying to "Nadim Kobeissi (@nadim@symbolic.software) (@kaepora)" = "Nadim Kobeissi (@kaepora)": NIST's report https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8309.pdf says, for totally unclear reasons, that 20,000 extra bytes is "unacceptable" in TLS key exchange. I ask for a rationale: https://groups.google.com/a/list.nist.gov/d/msg/pqc-forum/7aenKgDWV2k/RqlEHB2yDQAJ. NIST replies that other options are more efficient. This doesn't answer the question at all.
2020.07.30 06:37:15, replying to "Nadim Kobeissi (@nadim@symbolic.software) (@kaepora)" = "Nadim Kobeissi (@kaepora)": No, it isn't normal. Measured by asymptotic pre-quantum security levels, McEliece/ECDLP/AES are exactly as strong today against known attacks as they were at the time of their introduction in the 1970s/1980s/1990s. (Of course quantum computers break ECDLP and speed up searches.)
2020.07.30 06:43:40: FFDH is a different case, I agree, and also instructive: its structure led to a more and more complicated attacks reducing the security more and more. L(1/2) security conjecture was broken in the 1990s. L(1/3) security conjecture was broken in the 2010s for small characteristic.
2020.07.30 06:12:52, replying to "note to self. cease tweeting. (@int_ijk)": Slides from some introductory talks I gave about lattice-based cryptography a week ago: https://cr.yp.to/talks.html#2020.07.20-1 https://cr.yp.to/talks.html#2020.07.21-1 Includes summaries of 17 selected papers in the last decade, mostly 2018-2020, better breaking lattice-based cryptosystems in 6 different ways.
2020.07.30 05:16:32: In apparently coordinated announcements, NIST and NSA are strongly pushing for lattice-based crypto, specifically structured lattices, specifically cyclotomic lattices, including sizes where published attacks already seem to violate the minimum #NISTPQC security requirements.
2020.07.30 05:24:01: The claimed asymptotic lattice security levels were 42% higher just 10 years ago. They were superexponentially higher just 20 years ago. Structured lattices, especially cyclotomic lattices, raise further concerns. Gentry's original STOC 2009 FHE system is broken for cyclotomics.
2020.07.30 05:46:02: NIST's report says that if something even worse happens _publicly_ to cyclotomics _before standardization_ then it will reconsider its "confidence". Meanwhile it displays no understanding of the bigger picture of lattices indisputably losing security again and again and again.
2020.07.28 11:10:31: Misrepresentations of security proofs are starting to cause serious damage. The embarrassingly wrong idea that there's a proof that the "security of NewHope is never better than that of KYBER" is the centerpiece of NIST removing NewHope from #NISTPQC. See https://doi.org/10.6028/NIST.IR.8309.
2020.07.28 11:14:58: Known hybrid attacks are faster against Kyber than against NewHope. (Kyber missed this because its security analysis was oversimplified; I'm writing a paper on this.) More to the point, it's clear that there isn't and won't be a proof that Kyber is at least as secure as NewHope.
2020.07.28 11:26:26: Cryptographers who condone exaggerations of what has been proven share responsibility for any resulting security failures. We cannot simply ignore the increased influence of dangerously oversimplified "provable security" claims upon standards and deployment. This is not a game.
2020.07.23 18:15:07: The "ultra-short" signatures in https://eprint.iacr.org/2020/914.pdf do not reach their claimed security level: consider an attacker who simply sends random strings as forgery attempts. The user pays the verification cost, while the authors incorrectly attribute this cost to the attacker.
2020.07.22 15:01:03: After NIST's Dual EC standard was revealed in 2013 to be an actual (rather than just potential) NSA back door, NIST promised more transparency. Why does NIST keep soliciting private #NISTPQC input? (The submissions I'm involved in seem well positioned; that's not the point.)
2020.07.22 15:42:32: And, right on cue, NSA pops in on the #NISTPQC mailing list to thank NIST for its effort and to say that NSA has been asked by "many" of its "partners" about #NISTPQC. I don't want NSA's public statements; I want prompt public review of all input to the standardization process.
2020.07.15 06:37:40, replying to "Bram Cohen🌱 (@bramcohen)": There's some batching of primality tests in Section 3 of https://cr.yp.to/papers.html#pqrsa (executive summary of this part: https://cr.yp.to/talks.html#2018.07.19), which becomes more and more effective if you have to test more and more candidates for primes. (Deterministic; no need for witnesses.)
2020.07.14 09:39:37, replying to "Madars Virza 🛡 (@MadarsV)": There are many choices of "half-gcd" algorithms, including many 2-dim lattice-basis-reduction algorithms, but some care is required: almost all of the algorithms in the literature will leak secrets through timing. There are several solutions; easiest: compute s from random r, t.
2020.07.12 17:06:28, replying to "shlomtz(.eth) (@OmerShlomovits)": A little bit of compression is possible here too: the server broadcasting pairs (u,v) can arbitrarily scale the pairs, and can spend a little time searching for scales where v has some 0 bits that can be skipped. But there's a more interesting tradeoff in the other direction...
2020.07.12 17:12:24: The server can send along u; v; u^2^56; v^2^56. Double traffic, but now computing u^r v^t with 112-bit r and 112-bit t costs only 56 squarings (1/4 of the original), maybe 3x speedup when mults (or curve adds/subs) are included. For many more options: https://cr.yp.to/papers.html#pippenger
2020.07.12 17:21:52: At a lower level, the paper specifies P-224 (for BLE constraints) but tries to extrapolate from wolfSSL P-256 time (for keygen, which can be misleading). Since there are many (u,v) it should be better to work with affine coordinates and use Montgomery's batch-inversion trick.
2020.07.12 17:35:30: There's surely also a speedup from using a better prime. https://cr.yp.to/talks.html#2001.10.29 suggested the curve y^2 = x^3+7530x^2+x mod 2^226-5, with keys squeezed into 224 bits (this takes negligible extra keygen time). Also wondering if 25519 could squeeze into extra BLE metadata bits.
2020.07.12 15:08:40: The new CleverParrot exposure-notification protocol in https://eprint.iacr.org/2020/863 says your phone will spend 12 minutes per day checking, for your secret s, for many pairs u,v, whether u^s = v. Here's a nearly 2x speedup: check whether u^r v^t = 1 for half-size r,t with s = -r/t.
2020.07.07 15:20:21, replying to "Amin Sakzad (@AminSakzad)": The stated criterion was "haven't suffered security losses". Sure, submissions that suffered security losses hope to still be sufficiently secure, but security losses are warning signals regarding future risks. Asymptotic lattice security levels were 42% higher just 10 years ago!
2020.07.05 08:58:35: Warning: Patent https://patents.google.com/patent/US9094189B2, expiring 2032, covers subsequent LPR cryptosystem and derivatives such as Kyber, LAC, NewHope, NTRULPR, Round5, Saber, ThreeBears. Also, I'm increasingly skeptical of the idea that these avoid patent https://patents.google.com/patent/US9246675B2, expiring 2033.
2020.07.05 09:24:55: A British law firm named Keltie, not (as far as we can tell) saying who's paying it to do this, filed a formal objection to the 2032 patent. The patent was upheld. To see all documents (including a few interesting documents) and watch the ongoing appeal: https://register.epo.org/application?number=EP11712927&lng=en&tab=doclist
2020.07.05 09:34:25: I would love the patent to magically go away, but I find Keltie's objections unconvincing, and their star witness seems to be lying under oath. If this cryptosystem was already obvious in 2009, why did the 2010 LPR paper https://link.springer.com/content/pdf/10.1007%2F978-3-642-13190-5_1.pdf highlight a bigger, slower system?
2020.07.05 09:54:00: LPR encryption using noisy DH + reconciliation was published in talks starting 2010.04 and in later LPR paper updates, but patent on encryption using noisy DH + reconciliation was already filed 2010.02. I find 2009 publications with noisy DH, but no reconciliation, no encryption.
2020.07.05 10:08:19: As for the patent expiring 2033, as far as I can tell this is the original source of chopping ciphertext sizes by a factor of almost 2. Claims of obviousness are again undermined by a subsequent paper from an expert claiming the ciphertext-size reduction as his main contribution.
2020.07.05 10:12:18: For a while there has been a narrative that this patent applied to original NewHope (as in Google's CECPQ1) but not to modified NewHope (as in #NISTPQC), because of a minor change in the NewHope details. I doubt courts will care about this minor change. Ciphertext size is clear.
2020.07.05 10:17:12: Quotient NTRU is much older and had the same ciphertext size (actually, even slightly better), but it wasn't using noisy DH. Given the procedures that courts use to handle patent cases, I wouldn't be surprised if this patent ends up covering all compressed noisy-DH cryptosystems.
2020.06.30 15:38:36: The Crypto 2020 paper https://eprint.iacr.org/2020/812, unaware of known algorithms using more hardware to reduce latency of x |-> x^2^T mod N, asks the "ambitious" question of whether reducing latency is equivalent to factoring, and excitedly proves yes in a limited model of computation.
2020.06.30 15:48:28: In response to hype of older results in essentially the same model, Jager and Schwenk showed a decade ago that computing Jacobi symbols, which is doable in polynomial time, is as hard as factoring in this model. All results in this model need to preceded by huge security alerts.
2020.06.30 15:55:17: Similarly, the Crypto 2011 paper https://link.springer.com/chapter/10.1007%2F978-3-642-22792-9_43, unaware of Sendrier's support-splitting algorithm S, proved that the problem solved by S is hard in a model of quantum computation, and claimed this was evidence of McEliece hardness. The same model says sorting is hard!
2020.06.30 16:05:38: Sometimes proofs in limited models of computation are useful guidance for cryptanalysts, but for these papers the state-of-the-art attacks against the same problems were already beyond the proof models. We need to actively stamp out these dangerous "evidence of hardness" claims.
2020.06.28 00:56:55, replying to "Ján Jančár (@j08ny)": The fact that nonces _can_ be reduced doesn't eliminate the protection: simple implementations won't spend extra code on the reduction. Example: libgcrypt rolled its own and was still protected by the long nonces, the scenario described years earlier in https://mailarchive.ietf.org/arch/msg/cfrg/8z3ZcujGRxFSGEBI-uE7C1tjw4c/.
2020.06.27 15:06:38, replying to "Frank ⚡ (@jedisct1)": Page 31 of https://cr.yp.to/talks/2005.09.20/slides.pdf mentioned that setting high bit "avoids infinity and avoids timing attacks". This was six years before https://eprint.iacr.org/2011/232.pdf extracted keys from exactly this timing leak in OpenSSL. See also https://cr.yp.to/talks.html#2014.07.23 and https://mailarchive.ietf.org/arch/msg/cfrg/pt2bt3fGQbNF8qdEcorp-rJSJrc/.
2020.06.27 15:28:02: The high bit is an example of a much broader success story: many security failures in cryptographic implementations can be predicted by cryptographic designers and proactively avoided through changes in designs. See, e.g., https://cr.yp.to/talks.html#2015.01.07 and https://blog.cr.yp.to/20191024-eddsa.html.
2020.06.27 12:39:28, replying to "Amin Sakzad (@AminSakzad)": Not true. There have been various speedups to the state-of-the-art lattice attacks since then, affecting _all_ lattice submissions, including Titanium. There are some lattice submissions that had much bigger losses (e.g., Round2 was completely broken), but nothing was unaffected.
2020.06.27 12:31:05, replying to "Mike Gardiner (@ObstacleMan)": I suspect NIST starts round 3 by declaring a small list of things they plan to standardize + explicit backup list. But speed will be overemphasized: people are overconfident; risk is harder to prove than speed. I doubt all security problems will be caught before standardization.
2020.06.26 11:38:29: Which post-quantum submissions (1) haven't suffered security losses since the #NISTPQC competition began and (2) are among the 26 submissions in round 2 (which is ending soon)? I think there are exactly 3: SIKE (which scares me for being too new), Classic McEliece, and SPHINCS+.
2020.06.22 10:27:45, replying to "Ciprian Manea (@ovipic)": An example is the "FaCT" language: https://www.sysnet.ucsd.edu/~bjohanne/assets/papers/2019pldi.pdf
2020.06.22 08:52:44, replying to "damageboy (@damageboy)": Beware that most benchmarking frameworks don't reliably measure timings of software running on Intel CPUs with Turbo Boost. Cycles/second is variable for the CPU core and for perfmon, while it's constant for rdtsc (the usual cycle counter) and for DRAM. Have to control temps etc.
2020.06.20 21:23:37: This is clearly not the world's biggest problem in 2020, but it's still depressing to see the official software for Frodo (a high-profile candidate for post-quantum crypto) broken by a timing attack on memcmp: https://eprint.iacr.org/2020/743.pdf. We need more work on constant-time languages.
2020.06.20 20:42:09, replying to "Travis Downs (@trav_downs)": It's not just in sorting that papers systematically downplay the competition! For crypto we've built a centralized cross-platform benchmarking framework with an easy way for people to submit improved code. Sorting small int32 arrays is one part of this: https://bench.cr.yp.to/impl-sort/int32.html
2020.06.20 20:54:44: The graphs there are for sorting int32[768], a typical size of interest in crypto. Min-max instructions and vectorization make sorting networks much faster than radix sort on Intel chips. For much larger arrays the main optimization game would be to reduce cache misses.
2020.06.20 21:03:17: Am I correctly understanding that VxSort's AVX2 code takes 4ns on 2.8GHz Kaby Lake to sort int32[1000], around 11000 cycles? The graph shows 4897 Kaby Lake cycles (without Turbo Boost) for int32[768]; the same code (avx2 from djbsort) takes 6054 Kaby Lake cycles for int32[1024].
2020.05.30 19:48:19: Preliminary experiments with a domain-specific language for SIR/SEIR/... models: https://cr.yp.to/2020/sir-20200530.txt https://cr.yp.to/2020/seair-20200530.txt Preliminary tool to make epi.pdf graph: https://cr.yp.to/2020/epi2graph-20200530.py H/T @ve3hw for chemistry notation. Compare to model_spec in https://github.com/rajeshrinet/pyross/blob/master/examples/deterministic/ex16-Spp.ipynb.
2020.05.07 21:54:28, replying to "Melon Sucks (@BlauBaron)": Sure, it's possible that WHO etc. have been deliberately spreading false information to control resources. See @zeynep's brilliantly subversive piece https://www.nytimes.com/2020/03/17/opinion/coronavirus-face-masks.html from March. But there are other possibilities that I think are even _more_ worrisome.
2020.05.07 22:05:17: The analysis in https://nymag.com/intelligencer/2020/03/why-was-it-so-hard-to-raise-the-alarm-on-coronavirus.html persuasively attributes much broader COVID-19 failures to confirmation bias and other well-known cognitive biases. Is it hard to imagine that the recommendations from public-health organizations are driven primarily by confirmation bias?
2020.05.07 22:20:30: Scenario 1: A shortage of masks led WHO to issue a one-time pack of lies, thinking this would be for the greater good. Scenario 2: Confirmation bias led WHO to fool itself regarding asymptomatic spread, masks, etc. Which of these is more likely? Which of these is more worrisome?
2020.05.07 21:24:30: Reading many papers, I see (1) mechanistic evidence that #Masks4All and hand hygiene help limit COVID-19; (2) obviously no blind randomized controlled trials. Here's what's puzzling: How did some health organizations decide that hand-washing is "evidence-based" and masks aren't?
2020.05.07 04:58:17, replying to "Gautam Goel (@gautamcgoel)": There's already a quantum polynomial-time key-recovery algorithm breaking the cyclotomic case of Gentry's original STOC 2009 FHE system using ideal lattices (assuming h^+=1, the normal situation). Same for the original Eurocrypt 2013 Garg--Gentry--Halevi multilinear-map system.
2020.05.04 22:25:59: Understanding various approaches to risk management for post-quantum encryption: Classic McEliece = stay at home full time, for people who can afford it. NTRU Prime = go out when necessary, but with distancing and masks. Typical lattice-based cryptosystem = party like it's 2019.
2020.04.20 19:36:01, replying to "Yehuda Lindell (@LindellYehuda)": Clarification question: Is "doesn't help" a claim of _zero_ benefit? If not, what exactly _do_ you mean? If so, I can see where your attacks on this claimed "interpretation" come from, but how exactly do you get to this "interpretation" from the quote attributed to Diffie?
2020.04.20 09:57:22, replying to "Yehuda Lindell (@LindellYehuda)": Where did the quote attributed to Whit say the field wasn't successfully attracting usage? Here's the quote again: "Lots of people working in cryptography have no deep concern with real application issues. They are trying to discover things clever enough to write papers about."
2020.04.20 06:38:56, replying to "Yehuda Lindell (@LindellYehuda)": So each cryptographer claims success on the basis of the field of crypto as a whole having usage? Perhaps, but how would this marketing counteract the strong paper-writing incentive? Proactive security interferes with paper-writing and doesn't seem to add to total crypto usage.
2020.04.19 01:17:52, replying to "Yehuda Lindell (@LindellYehuda)": When I describe how the incentive structures in crypto lead to security failures for users, you object, saying the "field of crypto" is a "huge" success. You don't define the success metric but you categorically state that failures don't "take away" from it. Did I get that right?
2020.04.19 02:41:06: I wrote: "As a community we systematically refuse to measure and optimize how well we're doing at proactively avoiding errors and protecting users." As this thread shows, we respond to failures by declaring our field to be a "huge" success and saying the failures don't matter.
2020.04.19 00:32:19, replying to "Yehuda Lindell (@LindellYehuda)": Can you please state clearly which metric you're using for the allegedly "huge" success of the "field of crypto"? You keep giving alleged examples but not stating the metric. Readers can't figure out if the metric sees, e.g., OpenSSL's upcoming emergency patch as a failure.
2020.04.19 00:02:44, replying to "Yehuda Lindell (@LindellYehuda)": Sorry, I'm still missing answers to my clarification questions. I understand your examples of deployed crypto, but I don't understand what metric is being used to declare the "huge" success of the "field", and I don't understand what you think you're disputing in what I wrote.
2020.04.18 23:49:10, replying to "Thaddée Tyl (@espadrine)": The community doesn't (and doesn't want to!) systematically filter crypto through competitions, and doesn't catch all weaknesses in submissions to competitions. Rijndael's table-lookups-are-constant-time mistake wasn't publicly caught until years after AES standardization.
2020.04.18 23:22:56, replying to "Yehuda Lindell (@LindellYehuda)": Clarification questions: What's your metric for judging the "success"/"use" of the "field of crypto"? Where's the data showing the field is doing well in this metric? I get that you're praising the field, but it's really not clear what you're claiming and what you're disputing.
2020.04.18 01:40:12, replying to "JP Aumasson (@veorq)": It's not just "lots". The cryptographic community as a whole systematically flunks @nntaleb's "skin in the game" requirement for risk management. How often do we as cryptographers think that the damage caused by cryptographic failures will make _us_ suffer?
2020.04.18 01:47:09: Because we're driven primarily by publications, we have a perverse incentive to screw up again and again and again in supposedly new and exciting ways, so that we can continue writing papers. That's why as a community we keep ignoring users who ask us to be much more careful.
2020.04.18 01:49:05: Of course we put _some_ sort of requirements on cryptosystems to control the size of the literature and maintain the prestige of publications, but we have little incentive to match these requirements to what the users want, and we have an incentive _against_ being super-careful.
2020.04.18 01:56:02: We blame broken cryptosystems for being broken, and use them as motivation to build new cryptosystems. We refuse to assign any blame to the meta-system that keeps producing, and often deploying, one broken cryptosystem after another. We _want_ the meta-system. It gives us papers.
2020.04.18 02:02:08: As a community we systematically refuse to measure and optimize how well we're doing at proactively avoiding errors and protecting users. Avoiding errors would make papers too hard to write. Protecting users would make papers too hard to write. The incentive structure is broken.
2020.04.18 02:10:40: Is the problem just crypto papers? No. People specializing in writing crypto standards and people specializing in writing crypto software would also be damaging their own careers if they were as careful as the users wanted. Failure is rewarded by investment.
2020.04.17 04:47:35: Yesterday's soft deadline for #NISTPQC input has produced several interesting speed announcements. I'm biased but I think this is by far the most important: https://groups.google.com/a/list.nist.gov/d/msg/pqc-forum/wU0eKjbNB1k/pxv_J9ZrAgAJ The demo uses OpenSSL, so maybe wait until after next Tuesday's OpenSSL emergency security update.
2020.04.17 05:18:30: The round-1 keygen software was 6 million cycles. By the beginning of round 2 the keygen software was 1 million cycles. Google selected ntruhrss701, which has keygen around 272000 cycles, for CECPQ2. Now sntrup761 (fewer bytes, higher security) has keygen down to 166000 cycles.
2020.04.17 05:21:48: The main computational trick here is due to Peter Montgomery (who unfortunately passed away recently): you can replace N inversions with 1 inversion + 3N-3 mults by repeatedly using 1/a = b/ab, 1/b = a/ab. The new software merges inversions across a batch of 32 independent keys.
2020.04.17 05:28:04: The demo includes an OpenSSL "ENGINE" that transparently inserts the fast sntrup761 keygen into an unchanged browser (and an SSL terminator for the server) built on top of OpenSSL. The browser simply requests one key at a time as usual. Other applications work the same way.
2020.04.17 05:33:39: This is joint work with (in alphabetical order) Billy Bob Brumley, Ming-Shing Chen (leader for the new sntrup761 library), and Nicola Tuveri (leader for the new OpenSSL ENGINE). Paper should be coming in the not too distant future, but for the moment prioritized open-source demo.
2020.04.08 22:14:59, replying to "Samuel Clay (@samuelclay)": Thanks for the report. A syscall trace of wget -N (which works fine) vs. this Python script (which doesn't) shows pretty much the same HTTP request and reply, but after Python sees 'recvfrom(3, "", 8192, 0, NULL, NULL) = 0' (server EOF) it sits there for a minute and then chokes.
2020.04.08 22:35:08: I've dug a bit into Python's urllib3/response.py now, and I don't see where it has the "304 response cannot contain a message-body" logic required by RFC 7232 (and by previous 304 specs). It interprets 304 as saying 0 body bytes remain to transfer, but that's not the same thing!
2020.04.08 22:42:33: With HTTP's chunked encoding, a zero-length body is encoded as a nonzero-length string (so the receiver can see it's complete). For a 304 response, there's no body in the first place, and no encoded body. Unless I'm missing something, Python's urllib3 is violating the HTTP spec.
2020.04.05 21:38:34, replying to "Adam Langley (@agl__)": All of the data points in that article are consistent with the theory that Europe's lockdowns brought R far below 1, and with the theory that they didn't! Anyone claiming confidence one way or the other at this point is simply reporting preconceived notions (Bayesian priors).
2020.04.02 20:44:08, replying to "Eske Christiansen (@lebox)": No response to my initial email questioning the calculations and requesting the software. No response to my email specifically requesting confirmation that the unpublished software has this 55 typo. More broadly, no response regarding any of the problems that my paper identified.
2020.04.02 20:08:48, replying to "Jonathan Toomim (@jtoomim)": You think a skydiver's doctor should be free to choose claimed health interventions when there isn't a randomized controlled trial showing the interventions are effective? Evidence-based medicine clearly says that you must do nothing unless doing something has been proven better.
2020.04.02 19:45:58, replying to "Jonathan Toomim (@jtoomim)": WHO's non-recommendation of parachutes for healthy skydivers predates the specific followup paper that you're talking about. Under the rules of evidence-based medicine, WHO has to recommend inaction (e.g., not wearing a parachute) unless there's clear evidence _for_ the action.
2020.04.02 20:00:39: Of course, a new randomized clinical trial confirming the lack of effectiveness of parachutes helps the typical guided-by-intuition layperson understand how smart WHO has always been in never recommending parachutes for healthy skydivers in the first place.
2020.04.02 06:44:53, replying to "Ani Deshpande (@anidesh1)": See https://cr.yp.to/papers.html#gigo and the open-source Python scripts linked from there. The original paper that you're asking about has (among other problems) incorrect calculations, graphs, and conclusions within its own model, because it has a typo (55) in its unpublished software.
2020.04.02 01:29:10: Are you surprised to hear WHO saying that healthy skydivers don't need to and shouldn't use parachutes? This is backed up by a systematic review of randomized controlled trials, published in the British Medical Journal, cited more than 1000 times: https://www.bmj.com/content/327/7429/1459
2020.03.30 01:21:31, replying to "🔴@pdfkungfoo@meteo.social🐝🔋 #YesToNoCovid (@pdfkungfoo)": Daily increase is the bottom line, but the real importance of R0 is as an action item. If R0 is, say, 3, and if we can reduce the number of people we transmit to by a factor above 3 through widespread use of masks and hand-washing and telecommuting, then we win the COVID-19 war.
2020.03.30 00:59:19, replying to "Halvar Flake (@halvarflake)": https://cr.yp.to/2020/gigo-20200329.py is newer version of script. Documentation is now split off into Sections 2 and 3 of accompanying paper: https://cr.yp.to/papers.html#gigo Have started thinking a bit about the design of a domain-specific language to improve reviewability of computations like this.
2020.03.30 01:08:19: Regarding the initial question, China's reported "severe cases" peaked 25 days after lockdown: https://cr.yp.to/2020/nhc-20200329.py Maybe this means the same as what we'd call ICU occupation. Hospitals obviously have strong incentives to know and report their ICU occupation at each moment.
2020.03.30 00:51:44, replying to "🔴@pdfkungfoo@meteo.social🐝🔋 #YesToNoCovid (@pdfkungfoo)": Small changes in R0 have an exponential effect, yes, but R0=2 doesn't mean 2x every day: it means you're transmitting to 2 people on average during your infectious period after your incubation period. Even in crowded city with higher R0, hopefully incubation takes multiple days.
2020.03.29 23:21:19: Wrote paper https://cr.yp.to/papers.html#gigo disputing various overconfident claims in @StephenKissler distancing paper P. One software-verification aspect: P's safety claims are false in P's model; my paper reverse-engineers P's miscalculated graphs -> typo (55) in P's unpublished code.
2020.03.29 23:30:03: It's critical to understand actual impact of school closures, mask use, etc. Paper P models distancing as reducing R0 by at most 60%, and claims that (3) said 60% is what China's "intense" distancing did; but (3) didn't say this, and it's hard to reconcile this with NHC reports.
2020.03.30 00:03:45: https://www.sciencemag.org/news/2020/03/mathematics-life-and-death-how-disease-models-shape-national-shutdowns-and-other seems to say that overconfidence in early COVID-19 model is what produced initial UK policy. Some modeling papers track some sources of error but it's clear that the system as a whole produces a bias towards underestimating the total probability of error.
2020.03.30 00:11:32: Beyond the (obviously important) risk of errors in mathematical models of epidemics, there's a risk of errors in the software performing calculations based on those models, as illustrated by the P miscalculation shown in my paper. The literature doesn't adequately address this.
2020.03.30 00:22:07: Common software lifecycle: An applied mathematician learns how to build SIR/SEIR/... models. These models are differential equations. The mathematician writes a script using standard packages to solve differential equations. This script is software. Is the software correct?
2020.03.30 00:30:06: Even when the script is correct, there's no guarantee that the underlying standard packages are correctly solving the equations. They're designed for speed, with a fix-known-bugs approach to accuracy rather than a proactive safety-engineering approach.
2020.03.30 00:42:46: Sometimes people post their scripts. Sometimes they use interval-arithmetic techniques to guarantee solutions to their differential equations. But the overall picture is that epidemic-modeling software, despite its importance, isn't designed with verifiability as a primary goal.
2020.03.30 01:40:21: Here's the script that computes the graphs in my paper: https://cr.yp.to/2020/gigo-20200329.py See Sections 2 and 3 of the paper for documentation of what's going on inside the script, plus warnings. Also, https://cr.yp.to/2020/nhc-20200329.py plots the NHC "severe cases" data, the last graph in the paper.
2020.03.30 01:50:39: I need to take a bit of a break from this, but here are some to-do items for the software: build a domain-specific language for SIR/SEIR/... models, emphasizing reviewability; incorporate interval arithmetic; compute maximum ODE discretization errors, emphasizing provability.
2020.03.26 02:45:26: Astonished by the numbers in this Netherlands court decision. https://www.scmp.com/news/asia/southeast-asia/article/3077005/netherlands-ordered-pay-damages-indonesia-colonial Fundamentally broken legal system? Or a broader societal failure to place value upon human life beyond wages? Is this also what has been driving the Dutch response to the COVID-19 pandemic?
2020.03.26 00:22:23, replying to "(@Er1kTheRed)": I think reporters can move faster than legislators in providing the labels you're asking for. Example: "Prof. John Edmunds, who cannot be fired even if he's disastrously wrong about this, continued advising against a lockdown, claiming that it would merely delay the inevitable."
2020.03.25 06:35:33, replying to "(@Er1kTheRed)": "Amateur"? This is @neil_ferguson's main job. But I agree that the lack of review creates completely unnecessary risks. Today I implemented a simpler model from the new Harvard distancing paper, and (without vaccinations) I see critical-care overloads that they claim they avoid.
2020.03.25 05:53:12: Wrote a Python script to recalculate graphs from new @StephenKissler distancing paper: https://cr.yp.to/2020/gigo-20200324.pdf https://cr.yp.to/2020/gigo-20200324.py Almost matches, but what's the paper's initial pulse? The paper's 37.5 safety claim fails for some pulses, never mind other flaws in the model.
2020.03.25 07:22:09: The script also has many comments (target audience: Python programmers who enjoy math) to explain (1) SEIR mathematical models of epidemics and (2) specific issues with this paper's model. Script is easily tweaked to model handwashing+mask R0 reduction, future vaccination, etc.
2020.03.24 16:51:11, replying to "Martin R. Albrecht (@martinralbrecht)": A large prime q has chance only about R^2/q^2 of appearing as a stray prime. The total number of such q > R^3 is O(1/R); i.e., practically guaranteed not to happen. ECM finds all q <= R^3 in R^o(1) modular operations. Should be easy to double-check this with an implementation.
2020.03.24 18:25:56: The gcd inputs have R^(1+o(1)) bits, so the output can't have more bits, so each modular operation costs at most R^(1+o(1)) bit operations. The ECM stage thus uses at most R^(1+o(1)) bit operations. This works for any R^O(1) bound on the stray primes that appear.
2020.03.24 05:30:08: Increased critical care capacity is of course good, but here @StephenKissler also makes the unjustified claim that it's good to take advantage of such capacity by infecting people sooner. Adding the possibility of widespread mid-2021 vaccination to the model would flip the claim. https://twitter.com/StephenKissler/status/1242106527189778437
2020.03.24 05:57:12: Even within the paper's focus on distancing, the paper's quantitative conclusions start by assuming that distancing reduces R0 by _at most_ 60%. The paper claims, citing (3), that this is what China's distancing did. (3) does _not_ say this; it says that China did _at least_ 60%.
2020.03.26 06:01:14: Today there's another paper that---unlike the paper I've been criticizing---models the possibility of future vaccinations, and models survival as a goal. Unsurprisingly, the new paper concludes that allowing more people to be infected now is a bad idea: https://www.nber.org/papers/w26882
2020.03.24 05:14:12: The second sentence from @StephenKissler here is overstating what is actually shown in his paper. Most importantly, the paper analyzes only one intervention, social distancing, while assuming that all other interventions (e.g., widespread mask wearing) fail to reduce R0. https://twitter.com/StephenKissler/status/1242106525902090241
2020.03.24 03:18:47, replying to "Martin R. Albrecht (@martinralbrecht)": Why is there a (tau+1)/(tau-1) on the exponent of the attack cost? Computing gcd((x0-1)...(x0-R),(x1-1)...(x1-R)) uses R^(1+o(1)) operations, and then spending R^(1+o(1)) operations on ECM is practically guaranteed to trim away all the stray factors, even for tau as small as 2.
2020.03.22 08:52:27: Current Dutch government COVID-19 policies: https://archive.today/iKhYQ https://archive.today/WqXlo https://archive.today/Trr6W https://archive.today/uJIPT Are the claims (lockdown is "not useful", infection from touching surfaces is unlikely, etc.) generally believed in the Netherlands today?
2020.02.26 07:56:54: More evidence that people reviewing security of #NISTPQC candidates are dangerously overloaded: https://eprint.iacr.org/2020/241 gives (among other things) a simple fast attack completely breaking round-1 "Round2", the predecessor of round-2 "Round5". Attack wasn't noticed for two years.
2020.02.17 19:40:36, replying to "Sam (@sam280)": Compare that figure to the publicly verifiable sphincss128sha256simple benchmarks in https://bench.cr.yp.to/results-sign.html#amd64-hiphop: 8080-byte sigs, 914806052 cycles to sign, just 2688952 cycles to verify. If you aren't scared of non-standard hashes, sphincss128harakasimple is 613576 cycles to verify.
2020.02.17 20:08:09: My main concerns with Picnic, PorcRoast, etc. are the unstable security story for MPC-friendly primitives and the weak evidence for signature security (issues: many hashes; many targets; quantum attacks) even if primitive is secure. But they should also admit the verify slowdown.
2020.02.14 23:05:40: Looking forward to the talks at PQCrypto 2020 (@PQCryptoConf) in Paris: 29 accepted papers https://pqcrypto2020.inria.fr/papers/ plus an invited talk by Ben Smith on isogenies and an invited talk by NIST on standardization of post-quantum crypto. Early registration deadline is a week from now.
2020.02.09 13:00:29: Without taking calculus courses, people learn how to repeatedly differentiate to minimize bad news. Example: 37198 confirmed cases in China; bad. Rate of increase: 2652 more cases than the day before; bad. Rate of rate of increase: 2652 is less of an increase than earlier days!
2020.02.04 19:13:34, replying to "John Schanck (@susurrusus)": Let's work out the numbers for getting the obvious n=53 1000-gate attack done in 1 second. Parallelize across, say, 2^23 chips, each storing 2^30 floats and doing 2^40 simple ops/second. Spreading chips across 100m x 100m handles the heat. Speed of light is nowhere near an issue.
2020.02.05 23:42:44: Side note further confirming my model: Google's Nature paper https://www.nature.com/articles/s41586-019-1666-5.pdf also says that it uses the obvious space-2^n algorithm for as many qubits as it can (namely 43) given the amount of RAM on the target computer. Realistic parallelism gets latency down to 2^(n/2).
2020.02.04 18:04:10, replying to "John Schanck (@susurrusus)": IBM's "2.5 days" is bottlenecked by _disk_, precisely because they don't have enough RAM (which would cost roughly $100 million). "Treewidth" on slide 17 sounds like an allusion to vastly slower algorithms: Google estimates 10000 years for these circuits. Why do you claim faster?
2020.02.04 18:09:17: And, to be clear, the arxiv paper that you cite is one of the vastly slower algorithms for these circuits. Google skipped the obvious much faster algorithm because they didn't realize space 2^53 is feasible; this is questionable for legitimate users and wrong for attackers.
2020.02.04 16:49:22, replying to "John Schanck (@susurrusus)": You have the attack ordering backwards. One can massively slow down the obvious attack by replacing RAM with disk and it still takes (for n=53, as per IBM vs. Google) only a few days where the "better" attack takes 10000 years. RAM + special-purpose chips would be milliseconds.
2020.02.04 16:52:48: Regarding the algorithm details, it should be obvious that recomputing a path is slower than caching it, and all of the low-memory algorithms have _tons_ of recomputation. Aaronson is talking about (and claims that Google has) generic enough circuits that 2^n is the speed record.
2020.02.04 09:54:41, replying to "Noah @NoahSD@mathstodon.xyz (@NoahSD)": Certain people claim that the hardness of lattice problems has been studied since the time of Gauss and is well understood. Having one paper after another speeding up various lattice computations should put an end to this BS whether or not more lattice submissions are broken.
2020.02.04 09:35:25, replying to "John Schanck (@susurrusus)": The attacker can build much more attack hardware than the legitimate user, arbitrarily parallelizing the space-2^n attack. The user-verifiable n is small. Aaronson's "faraway skeptic" doesn't impose a nearly low enough latency limit for speed-of-light limits to stop the attack.
2020.02.04 09:42:06: After computing the distribution of 2^n outputs (16-bit accuracy is overkill), the attacker samples from the distribution (don't even have to bother adding fake errors given the protocol definition), using a hidden PRNG seed. This directly violates the "certified randomness".
2020.02.04 10:21:01: I think I've diagnosed the conceptual mistake that led to this broken protocol. The primary argument for algorithms using vastly more than 2^n time, but less space, is that the legitimate user can't afford 2^n RAM. Conceptual mistake: thinking that attackers can't afford 2^n RAM.
2020.02.03 22:03:15, replying to "John Schanck (@susurrusus)": That slide claims to be able to extract "10 certified random bits" in "a few seconds", whereas I'm saying that the obvious attack completely breaks the protocol for every n that's feasible to verify. Seems clear that the slide is based on a worse attack. Why do you claim better?
2020.02.03 14:30:18, replying to "Jonathan P. Dowling (@jpdowling)": It is also possible that there is a fast quantum attack against all QKD schemes, or even a fast non-quantum attack. See generally https://cr.yp.to/papers.html#holographic. QKD keeps getting broken this way, despite its limited functionality (basically, trying to replace AES) and massive funding.
2020.02.03 14:18:16, replying to "Shozab Qasim (@SQ_PCMP55)": Quantum cryptography, despite its "provable security" claims and massive funding, has a much worse security track record than post-quantum cryptography. See, e.g., the neverending series of breaks on http://www.vad1.com/publications/. For a broader perspective see https://blog.cr.yp.to/20160516-quantum.html.
2020.02.03 13:29:23: Obvious attack that breaks the "certification" of randomness in https://www.scottaaronson.com/talks/certrand2.ppt: standard space-2^n computation of circuit state, parallelized as necessary to meet latency requirement. This attack is feasible since the "HOG" circuit verification step forces n to be small.
2020.02.03 13:41:21: Scientifically, it's surprising to see the lack of citation to time-lock puzzles and verifiable delay functions, which (1) similarly hope that latency limits can stop a massively parallel attacker from outperforming the verifier, and (2) choose harder-to-parallelize computations.
2020.02.03 12:26:49: This news reminds me of the European Space Agency in https://hyperelliptic.org/DIAC/slides/ESA-Contribution-to-DIAC-2012.pdf saying that "human beings" usually cannot "access flying spacecraft" so "there is no need for side channel attack protection". Serious attackers build machines to carry out attacks beyond human ability. https://twitter.com/M_R_Thomp/status/1222990126650994698
2020.02.03 11:31:33, replying to "Noah @NoahSD@mathstodon.xyz (@NoahSD)": https://eprint.iacr.org/2019/1436 from Kirchner, Espitau, Fouque. Sounds like >1000x from the Galois structure, plus some general speedups. The approximation factor and consequences for BKZ aren't clear. The point I was making is that lattice security wasn't, and isn't, well understood.
2020.01.28 00:51:40: BSI filed comments with NIST claiming, falsely, that some Brainpool curves were "standardised in RFC 5639": https://csrc.nist.gov/csrc/media/publications/fips/186/4/final/documents/comments-received-fips186-4-december-2015.pdf NIST now proposes to officially allow the Brainpool curves in SP 800-186 for "interoperability". Comments due 29 Jan: https://www.federalregister.gov/documents/2019/10/31/2019-23742/request-for-comments-on-fips-186-5-and-sp-800-186 @ietf
2020.01.18 19:53:05: It's fascinating to compare how the same Salsa/ChaCha attack paper https://tosc.iacr.org/index.php/ToSC/article/view/574 is described in https://keccak.team/2017/not_arx.html ("very hard to estimate the security") and https://131002.net/data/talks/TMC-RWC20.pdf ("attacks don’t really get better"). How can we protect against confirmation bias?
2020.01.15 20:35:01, replying to "hanno💉💉💉💉 (@hanno)": See https://cr.yp.to/newelliptic/nistecc-20160106.pdf (from @hyperelliptic and me), which says in §1 that "unnecessary complexity in ECC implementations" creates "ECC security failures", and says in §11 that allowing run-time curve choices causes "obvious damage to implementation simplicity". Told ya so.
2020.01.09 16:31:13: Does Apple's "Find My" really force an otherwise quiet device to continuously broadcast its 15-minute visible identity (MAC addr, FM key, etc.)? Maybe safer: devices all try to switch identities at :00,:15,:30,:45, and do just 1 broadcast at a random time in each identity period.
2019.11.24 01:19:25: Amazing compendium of failures of "provable security": https://eprint.iacr.org/2019/1336. I saw a preprint months ago and the shock value of the huge lists still hasn't worn off. I think (and hope) this will put an end to the delusion that provable-security failures are isolated mistakes.
2019.11.22 12:19:42: Final schedule online for ECC 2019, the 23rd Workshop on Elliptic Curve Cryptography: https://eccworkshop.org/2019/schedule.html Still a few days left to register: https://eccworkshop.org/2019/reg.html We'll have to close registration at the end of the 27th to finalize arrangements for the dinner etc.
2019.11.21 23:51:45: 65.98 cycles/byte for SHA-512 on common Cortex-M4 microcontrollers (assuming all CPU options and no wait states). Best "optimizing" compiler result I've seen for reasonable C code is 110 cycles/byte, which is embarrassing for such a simple CPU. Does anyone have a better compiler?
2019.11.13 09:42:59: Registration links now open for ECC 2019, the 23rd Workshop on Elliptic Curve Cryptography: https://eccworkshop.org/2019/reg.html Only 115 EUR student registration, 230 EUR regular registration. Speaker list and draft schedule: https://eccworkshop.org/2019/schedule.html Travel+hotels: https://eccworkshop.org/2019/travel.html
2019.11.02 16:40:06: Security experts: If we dismiss QKD based merely on its massive cost, without highlighting QKD's many security flaws, then we're partly responsible for governments diverting massive security funds to QKD. "QCI": https://ec.europa.eu/digital-single-market/en/news/future-quantum-eu-countries-plan-ultra-secure-communication-network Pseudo-science PDF: https://etendering.ted.europa.eu/document/document-file-download.html?docFileId=68917
2019.11.02 16:47:10: Explaining security to people takes work. It's still something we have to do. "A computing professional should be transparent and provide full disclosure of all pertinent system capabilities, limitations, and potential problems to the appropriate parties." https://www.acm.org/code-of-ethics
2019.11.01 16:25:14: It turns out that BouncyCastle implements Ed25519 with code designed from the ground up to be constant-time, and has been making some progress in removing variable-time code elsewhere. Added a note about this to https://blog.cr.yp.to/20191024-eddsa.html (inside "Case study #9"). H/T Peter Dettman.
2019.10.27 23:58:09: Great news regarding ECC 2019, the 23rd Workshop on Elliptic Curve Cryptography (https://eccworkshop.org/2019/schedule.html): Registration fees will be only 115 Euros for students, only 230 Euros for regular registration. Mark your calendars! Will tweet as soon as registration link is available.
2019.10.25 07:13:52: New blog post "Why EdDSA held up better than ECDSA against Minerva": https://blog.cr.yp.to/20191024-eddsa.html Cryptosystem designers successfully predicting, and protecting against, implementation failures. #ecdsa #eddsa #hnp #lwe #bleichenbacher #bkw
2019.10.15 14:26:28: Happy to announce another confirmed speaker for ECC 2019, the 23rd Workshop on Elliptic Curve Cryptography (https://eccworkshop.org/2019/schedule.html): Meltem Sonmez Turan from NIST on lightweight-cryptography standardization. Registration for the conference will open soon.
2019.10.04 19:01:00, replying to "Paul Crowley (@ciphergoth)": Looking at the (horrifying) libgcrypt code, I would say that they tried hard to write a vulnerable implementation, and succeeded for ECDSA, but _didn't_ succeed for EdDSA. The double-size Ed25519 hash means that they would have needed an extra reduction step to enable the attack.
2019.10.04 19:25:30: There have been many other timing-attack vulnerabilities in libgcrypt, and clearly there will be more. We have to throw away variable-time crypto code _without_ waiting for attacks to be demonstrated. But this particular libgcrypt EdDSA attack is stopped by the double-size hash.
2019.10.04 20:17:40: Here's a CFRG message five years ago describing exactly this scenario, where the double-size EdDSA/Ed25519 nonces prevent damage from a "timing attack revealing the nonce length" if the implementor hasn't done extra work to reduce modulo the group order: https://mailarchive.ietf.org/arch/msg/cfrg/8z3ZcujGRxFSGEBI-uE7C1tjw4c
2019.08.03 21:55:26, replying to "SYNTHORN (@Synthorn)": SUPERCOP is a benchmarking repository that has accepted 3292 implementations (so far) of 1121 cryptographic functions. It benchmarks MD5. It benchmarks code from OpenSSL. There are many different limits in implementations. SUPERCOP has never made guarantees to "downstream users".
2019.07.28 19:12:12, replying to "Justine Tunney (@JustineTunney)": Thanks for the details. It looks like the code base you started from is the 2017 NTRU Prime code, which is multiple generations behind djbsort (https://sorting.cr.yp.to). See, e.g., https://bench.cr.yp.to/web-impl/amd64-titan0-crypto_sort.html for the Haswell speed gap between "oldavx2" and "avx2".
2019.07.27 11:44:24, replying to "Justine Tunney (@JustineTunney)": Thanks for taking a look. Which code base were you starting from, and which size did you try measuring? djbsort-20180729 uses a different minmax structure with asm from @zx2c4; your approach lets the compiler do all moves, which might be better.
2019.07.04 09:52:13: Frodo round 1 assumed "IND-CPA" in its first theorem. Frodo round 2 changed "IND-CPA" to "OW-CPA" in theorem statement; changed "IND-CPA" to "OW-CPA" in separate summary; added a footnote on "IND-CPA" vs "OW-CPA". I disputed theorem. Now they claim that this change was a "typo".
2019.07.04 10:02:08: "Security proofs" are supposed to be limiting and simplifying the cryptanalytic targets. "IND-CPA" is a decisional assumption like DDH. "OW-CPA" is a simpler search assumption like DH. "OW-CPA" is "falsifiable" under Naor's definitions; "IND-CPA" is only "somewhat falsifiable".
2019.06.25 11:46:22: Brier, Ferradi, Joye, Naccache in https://eprint.iacr.org/2019/484.pdf claim 2^256 security for factoring p^29 q where p and q each have 512 bits. ECM easily breaks this. The claim seems to start from https://keylength.com saying 512-bit primes, but that's for group sizes in Schnorr etc.
2019.06.25 19:28:19: After the same talk, Dan Boneh commented that the factoring algorithm from https://crypto.stanford.edu/~dabo/pubs/abstracts/prq.html should be even faster than ECM here. I wonder which of these attacks is a bigger constraint if one is trying to increase the size of p^29 q to reach 2^256 security.
2019.06.23 20:01:25, replying to "Paulo Barreto (@pbarreto)": There's a previously identified problem for common dimensions such as 1024; see https://eprint.iacr.org/2016/360. I heard @ChrisPeikert give a talk to a https://nap.edu committee where he claimed "a few thousand" would allow proofs. I'd love to see a complete proof handling 10000.
2019.06.23 09:46:09: Have you heard (repeatedly) about the worst-case-to-average-case reduction for LWE? Sarkar and Singha (https://eprint.iacr.org/2019/728) say that a step in Regev's proof requires the lattice dimension to be at least 187150. New research question: Can an optimized proof get down to 10000?
2019.06.22 22:45:39, replying to "Jonathan Bootle (@BootleJonathan)": Kuperberg's 2011 paper says roughly 2^sqrt(2n) for scaling the number of queries (never mind the huge polynomial cost for each query). The new paper does not claim any improvement in the exponent. To put this in perspective: SVP exponents dropped from 0.415 to 0.292 this decade.
2019.06.19 11:11:18, replying to "Steven Galbraith (@EllipticKiwi)": The literature has plausible physical architectures for getting to a huge number of qubits. It doesn't have plausible physical architectures for low-cost fault-tolerant quantum access to large arrays. See, e.g., https://arxiv.org/pdf/1502.03450.pdf, which Peikert's paper simply ignores.
2019.06.19 11:02:37, replying to "Chris Peikert (@ChrisPeikert)": Given the lack of definitions and explanation, I'm having trouble figuring out what you think you're disputing here. Are you saying "closer to" means under 2^60, rather than specifically 2^56? Or is "quantum security" secretly referring to something other than "qubit operations"?
2019.06.19 00:40:14, replying to "Chris Peikert (@ChrisPeikert)": Claim made in the paper, under very optimistic assumptions, some of which are stated explicitly: "CSIDH-512 does not achieve the claimed 64 bits of quantum security." Next sentence of the paper: "A more prudent estimate would be closer to 40 + 16 = 56 bits of quantum security."
2019.06.18 23:55:54, replying to "hanno💉💉💉💉 (@hanno)": No, CSIDH is fine. All known attacks are exponential in n^(1/2+o(1)), and the question is simply how big the o(1) is. For CSIDH-512 in particular, the new paper is claiming a total of 2^56 qubit operations, but this is under very optimistic assumptions for the attacker.
2019.06.13 05:14:54: Implementing gcd/xgcd/modinv? Heard about Microsoft SymCrypt gcd running forever (https://bugs.chromium.org/p/project-zero/issues/detail?id=1804) and OpenSSL gcd leaking secret keys via timing (https://eprint.iacr.org/2018/367)? Bo-Yin Yang and I have a paper https://cr.yp.to/papers.html#safegcd with a simple constant-time gcd algorithm.
2019.05.22 15:38:39: Cryptographers working on "verifiable delay functions" (VDF) seem to think that all known algorithms to compute x^2^T mod pq (unknown p,q) need T times the latency of a single squaring. Sorenson and I have a 2007 paper https://cr.yp.to/papers.html#meecrt beating this in some hardware models.
2019.05.22 16:09:01: Offhand I'd expect the real speedup to grow as Theta(log(hardware)). Of course there's no substitute for implementation measurements. This is yet another part of the ongoing denial-of-service attack against cryptanalysts: there's far too much new cryptography to seriously review.
2019.05.18 23:58:05: Very happy with the lineup of speakers we have for Surveillance, Privacy, and You (SPY) on Sunday: https://projectbullrun.org/spy/schedule.html One of several interesting parallel workshops this weekend in Darmstadt before #eurocrypt2019.
2019.05.14 06:57:00, replying to "ICMC (@CryptoModConf)": Title is "Does open-source cryptographic software work correctly?" Thursday, 10:15, Cambie.
2019.04.30 17:13:16: New blog post "An introduction to vectorization": https://blog.cr.yp.to/20190430-vectorize.html Understanding one of the most important changes in the high-speed-software ecosystem. #vectorization #sse #avx #avx512 #antivectors
2019.04.24 18:24:58, replying to "Stefan Kölbl (@kste_)": I don't think Cannon Lake has VAES. Regarding 256 vs. 128, ChaCha20 has a 256-bit key, and the benchmarks have two aes256ctr implementations using AES-NI (dolbeau and openssl, with similar speeds), so I compared to those. Nobody has bothered adding similar aes128ctr code yet.
2019.04.24 17:00:24: 0.57 cycles/byte for ChaCha20 to encrypt 4KB on one core of new Intel Cannon Lake CPU. I haven't seen AES-256 results as fast as this on the same CPU, even though AES-256 has special hardware support and much smaller security margin. https://bench.cr.yp.to/results-stream.html#amd64-cannon
2019.04.24 17:05:09: NSA's Speck software handles 4KB at 0.56 cycles/byte on this CPU, but only if you scale the block size down to 64 bits (broken by https://sweet32.info), scale the key size down to 96 bits (broken by easy multi-target attacks), and allow even less security margin than AES.
2019.04.07 19:14:19, replying to "Kostas Kryptos (@kostascrypto)": There's always pressure on these projects to support more cryptographic functions; I'll be the first to agree that we need some post-quantum functions. To allocate verification effort sensibly, one has to understand how the cost of verification depends on the choice of function.
2019.04.07 19:28:35: Regarding pre-quantum ECC, the issue isn't that implementations of the NSA primes, NSA curves, etc. are impossible to verify. It's that they're unnecessarily difficult---and of no real value for end users. Meanwhile more important projects are in desperate need of verification.
2019.04.06 13:17:53: Another example of how easy it's becoming to deploy cryptographic software formally verified to be bug-free: https://www.microsoft.com/en-us/research/blog/evercrypt-cryptographic-provider-offers-developers-greater-security-assurances/ As in NaCl, the only public-key option is ECC, and the only curve is Curve25519. Asking for RSA-2048 for "algorithm agility" = asking for bugs.
2019.04.06 13:32:43: It's unfortunate that Microsoft's EverCrypt advertising doesn't highlight the impact of design choices in cryptographic functions. (They even pick a picture with special cases that 25519 eliminates!) This is even more important for verifying more complex post-quantum software.
2019.03.21 08:51:26: "Let's take code from the SUPERCOP benchmarking framework. Does this file supercop/crypto_stream/salsa20/e/amd64-xmm6/warning-256gb mean anything? Probably not." [Time passes] "BREAKING NEWS: We found that this implementation doesn't work after 256GB!" https://groups.google.com/forum/#!msg/golang-announce/tjyNcJxb2vQ/n0NRBziSCAAJ
2019.03.21 00:59:53: Over the past day a quick demo of the #angr binary-analysis toolkit turned into a prototype verifier https://cr.yp.to/2019/unrolldemo-20190319.html checking correctness of Seiler's vectorized NTT asm in Kyber (see https://eprint.iacr.org/2018/039). Shouldn't be hard to generalize to many more linear maps mod q.
2019.12.27 08:39:28: Did a few cleanups and updates to recognize optimizations in the latest versions of angr. Same URL.
2019.03.12 22:09:32: Dozens of two-pagers, including "Post-quantum cryptography: NIST's competition heats up" from @hyperelliptic and me. https://twitter.com/KPN/status/1105391956283322368
2019.03.05 16:43:54: Bo-Yin Yang and I have a new paper "Fast constant-time gcd computation and modular inversion": https://gcd.cr.yp.to/papers.html#safegcd Much faster than earlier constant-time Euclid variants. Case studies: new speed records for 2^255-19 inversion (even faster than Fermat!) and NTRU-HRSS keygen.
2019.01.06 18:40:30: RWC2019 has some talks on formal verification, where a computer takes care of tediously checking for all the little mistakes that humans tend to miss. Particularly looking forward to the verification talk by Bhargavan, or, as the schedule says, "Bhargava". https://web.archive.org/web/20181227085308/https://rwc.iacr.org/2019/program.html
2019.01.02 09:07:37: Dear @nature editorial board: Please withdraw the following statement, which is (1) false and (2) thoroughly deceptive. "Specialists also point to problems for which quantum computers have long been known to have a proven advantage, such as web searches." https://www.nature.com/articles/d41586-018-07801-3
2018.12.29 17:11:07: Video available for #35c3 talk "The year in post-quantum crypto" from @hyperelliptic and me: https://media.ccc.de/v/35c3-9926-the_year_in_post-quantum_crypto Also slides: https://fahrplan.events.ccc.de/congress/2018/Fahrplan/system/event_attachments/attachments/000/003/695/original/slides.pdf "A journey through selected recent highlights from the post-quantum world." #nistpqc #pqcrypto #quantumcyberblockchain
2018.12.29 15:53:25, replying to "Dean Pierce 🌲🤖🚀👨💻 (@deanpierce)": Sorry, I didn't mean to say anything about the history of post-quantum blockchains as a technical concept. What I'm wondering is whether the groundbreaking marketing phrase "quantum cyber blockchain" predates @nickm_tor using it in 2016.
2018.12.24 08:02:02: US govt sends $1.2B to quantum salesmen making false promises: e.g. "Quantum computers will be able to sort rapidly through data sets that are too large to ever be stored on conventional devices, such as real-time video of the entire surface of the earth." https://www.lightourfuture.org/getattachment/85484dca-465a-46f4-8c8c-090aeb845d09/FINAL-Action-Plan-for-a-NQI-Apr-3-2018.pdf
2018.12.24 08:26:59: Of course money at this scale gets spread around. I could apply for some of it. There are similar programs starting or underway in many other countries. Pretty much every scientist in the area has a clear incentive to support the funding, even if this means deceiving the public.
2018.12.19 02:09:16, replying to "Brian Fitzpatrick (@therealfitz)": A study at normal reading distance (https://onlinelibrary.wiley.com/doi/abs/10.1002/asi.4630350606) found that all-caps is just as easy to read. Have you found contrary studies? People often claim that all-caps is slower because of word shapes; however, the word-shape model is discredited. See https://docs.microsoft.com/en-us/typography/develop/word-recognition.
2018.12.18 08:28:38, replying to "Brian Fitzpatrick (@therealfitz)": See https://nametags.cr.yp.to for the 15-year history here. I think you're right to recommend using extra vertical space (if available) to list interests, but wrong to recommend lowercase. Try looking at, e.g., size-adjusted "Brian" and "BRIAN" from longer and longer distances.
2018.12.16 13:23:16: Streamlined NTRU Prime 4591^761 keygen was previously 6 million cycles on Haswell. New software (in latest release of SUPERCOP benchmarking toolkit) is only 980000 cycles. https://groups.google.com/a/list.nist.gov/d/msg/pqc-forum/7tgYoT8M84E/rWFBm76xDwAJ The ideas will also speed up NTRU-HRSS keygen and some other post-quantum software.
2018.12.15 13:48:34: UK data-protection authority issues new encryption guide: "The RSA algorithm is one of the first public-key systems and is used for secure data transmission. It has a potential maximum key size of 4096-bits." https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/encryption/how-should-we-implement-encryption/ Does this mean post-quantum RSA violates GDPR?
2018.11.23 14:34:21: PQCrypto 2019 abstract deadline coming up tomorrow: http://pqcrypto2019.org/ Full submissions are due a week later.
2018.11.17 03:39:02: Dyakonov on quantum computing: "The most optimistic experts estimate it will take 5 to 10 years. More cautious ones predict 20 to 30 years. (Similar predictions have been voiced, by the way, for the last 20 years.)" https://spectrum.ieee.org/computing/hardware/the-case-against-quantum-computing Really? Which expert said 5-10 in 1998?
2018.11.17 03:54:21: Some parts of Dyakonov's article, such as his claim that the precision needed for fault tolerance has "never" been analyzed, are easy to disprove. But his "predictions" claim makes me wonder if anyone has collected a list: expert X in year Y predicted quantum computers in year Z.
2018.11.15 04:27:19: I'm puzzled that OpenSSL classified PortSmash severity as "low". https://www.openssl.org/news/secadv/20181112.txt I realize that the OpenSSL security policy (https://www.openssl.org/policies/secpolicy.html) defines "hard to exploit" timing attacks as "low" severity, but is someone claiming that PortSmash is "hard to exploit"?
2018.11.10 01:03:52: "On the impact of decryption failures on the security of LWE/LWR based schemes" (D'Anvers, Vercauteren, Verbauwhede) https://eprint.iacr.org/2018/1089: complicated analysis; varying levels of security damage. Doesn't mention the simple low-cost solution: eliminate all decryption failures.
2018.11.01 17:54:28: "Quantum circuits for the CSIDH: optimizing quantum evaluation of isogenies." https://quantum.isogeny.org New paper and quantum software from @hashbreaker, @hyperelliptic, @chloelono, @yx7__. #elliptic #isogenies #csidh #circuits #constanttime #reversible #quantum #cryptanalysis
2018.11.01 01:28:37: Wow: Inoue and Minematsu announce a fast attack breaking OCB2. https://eprint.iacr.org/2018/1040 OCB2 appeared at Asiacrypt 2004; advertised provable security; is a current ISO standard. OCB3 seems safe, and Rogaway has been recommending OCB3 for years, but the OCB2 story is terrifying.
2018.10.12 18:02:37, replying to "Gregory Neven (@gregoryneven)": The question at hand isn't whether the non-tight ROM proof is useless. The question is whether it's so strong that it justifies skipping key prefixing. The answer is no: key prefixing _eliminates_ multi-target attacks as a concern for auditors, while the non-tight proof doesn't.
2018.10.12 07:10:08, replying to "Pieter Wuille (@pwuille)": Even if we assume that the best DL algorithms cost 2^128, a cost-2^64 generic-hash attack against the Schnorr signature system would not contradict any of the ROM theorems that I've seen supposedly proving security of the system. It's important to read what the theorems say.
2018.10.12 03:38:23, replying to "Gregory Neven (@gregoryneven)": No. The ROM proofs for Schnorr signatures are too weak to be useful. The _real_ argument for security is that some cryptanalysts have tried and failed to break the system. But how many cryptanalysts have tried attacking multiple Schnorr users? Key prefixing answers this question.
2018.10.11 17:08:42, replying to "Gregory Neven (@gregoryneven)": The chance of breaking 1 of N signature users with key prefixing is at most the chance of breaking a targeted user in the original system. Simple; tight; real H, not ROM; eliminates concerns about multi-user attacks. Theorems without key prefixing have questionable assumptions.
2018.10.10 18:29:18, replying to "Gregory Neven (@gregoryneven)": Not true. https://eprint.iacr.org/2016/191 makes assumptions that are stronger and that have been less studied by cryptanalysts. Including the public key in the hash gives a multi-user security proof from _standard_ assumptions. (Side benefits: simpler, and quantitatively a bit stronger.)
2018.09.28 22:29:28: "What do quantum computers do?" https://cr.yp.to/talks.html#2018.09.26 Focusing on the core quantum instructions that programmers need to know. Emphasizing examples much more than formulas. Trying hard to eliminate unnecessary terminology (e.g., unitaries) and unnecessary notation (e.g., kets).
2018.09.27 21:07:31: Seems like a good moment to mention that, under Qubes, I have one browser window in one VM logged into Twitter, and a separate browser window in a separate VM logged into Google. The browsers aren't sharing any data. The window frames have different colors for the different VMs.
2018.09.19 00:22:56, replying to "thomas greenhalgh (@likothecat)": In Firefox, the relevant button is "Switch to Presentation Mode" (four arrows pointing outwards). In Chromium, it's "Fit to Page" (also a four-way icon). In both cases, left and right arrows move between the successive displays as expected.
2018.09.18 23:34:52, replying to "λarsw (@larsw)": I'm not sure whether there's a proper full-screen PDF viewer in Safari. But, starting from Safari, you can simply click on the up arrow followed by "Copy to iBooks". This opens iBooks, and then you can slide your finger along the thumbnails at the bottom.
2018.09.18 21:47:53: Experimenting with several variants of the TEA cipher as a teaching tool (TEAching tool, I guess) for cipher cryptanalysis: https://cr.yp.to/talks/2018.09.18/slides-djb-20180918-primitives-4x3.pdf Are there any common cipher attacks that _can't_ be illustrated with TEA or minor variants of TEA? See also https://www.rose-hulman.edu/~holden/Preprints/stea-paper-revised.pdf.
2018.08.31 00:38:10, replying to "Marc Stevens (@realhashbreaker)": Your comparison is bogus. The paper you're claiming to beat sacrificed two orders of magnitude in performance (Figure 1) to allow massive parallelization. Massive parallelization is critical for larger-scale attacks and exactly what _hasn't_ been shown to be possible for sieving.
2018.08.26 12:06:27, replying to "mjos\dwez (@mjos_crypto)": This is called "implicit rejection". It does _not_ magically turn decryption failures into decryption successes. It does _not_ stop the attacker from seeing the pattern of decryption failures, which is exactly the information exploited in (e.g.) the 2003 break of NTRU IND-CCA2.
2018.08.25 08:54:32, replying to "mjos\dwez (@mjos_crypto)": I'd like to know the status of the IND-CCA2 security claims that the Round5 team issued for the initial version of Round5 published earlier this month. Is the Round5 team withdrawing the claims given Hamburg's attack? Your tweets seem to suggest that the answer is no. #NISTPQC
2018.08.25 07:47:23, replying to "mjos\dwez (@mjos_crypto)": Let me see if I understand. You're agreeing with Mike that it's feasible for the attacker to find occasional Round5 ciphertexts that fail (contrary to the failure rates claimed in the Round5 specification), but you're nevertheless continuing to claim IND-CCA2 security for Round5?
2018.08.24 21:07:41: PKE/KEM decryption failures strike again: https://groups.google.com/a/list.nist.gov/d/msg/pqc-forum/YsGkKEJTt5c/V0eivEroAAAJ Looks like Hamburg has broken the new (patented?) Round5 proposal to #NISTPQC. Round5 is a semi-merge of HILA5 with the (patented) Round2 proposal; by "semi-merge" I mean that it has some new design elements in it.
2018.08.22 19:20:50: Has anyone verified the details of https://eprint.iacr.org/2018/699? This is the latest attack against NSA's Simon cipher. The central claim is that the smallest version of Simon is broken for 27 rounds, i.e., almost 85% of the full 32 rounds. Best previous result was 23, already scary.
2018.08.19 20:46:47: "Responsible disclosure" as defined by recalcitrant company where security is not job #1: you (1) find security problem, (2) write an exploit, (3) spend time discussing with company, (4) publish exploit. A better alternative, "accelerated responsible disclosure": do #4 before #3.
2018.08.19 20:37:07: Unlike https://eprint.iacr.org/2018/749.pdf, I recommend: 1. Require+verify DH primality proofs, as in https://cr.yp.to/ecdh/curve25519-20051115.pdf and https://safecurves.cr.yp.to/primeproofs.html. 2. Standardize primes so this is cheap. 3. Ignore nitwits writing "the appendix that shows that 3 numbers are prime should be removed."
2018.08.22 22:01:11: The quote is excerpted from the entertaining collection of anonymous reviews of the original Curve25519 paper. See https://cr.yp.to/talks.html#2016.03.09 for more.
2018.08.02 15:39:31: Patching ACPI DSDT on your new Lenovo ThinkPad X1 Carbon 6th gen to get normal S3 suspend working under Linux? I'm looking for people to test a kernel patch so that the DSDT patch can be avoided in the future: https://marc.info/?l=qubes-users&m=153308905514481&q=p5 Works for me.
2018.07.31 01:31:07, replying to "@js@mstdn.io (Jonathan S.) (@Midar3)": Should one write 1000 lines of code when 2 lines would do? Sometimes there's a good reason for this (e.g., optimizing hot spots), but much more often it's for bad reasons. This helps turn our computer systems into an unauditable mess. It turns out that there's a legal equivalent.
2018.07.30 23:27:21, replying to unknown: This German court case is directly on point: a public-domain dedication means that the software is free to use. It would be bizarre if this granted _less_ freedom than BSD, GPL, etc. I see no citations to courts expressing different opinions. No-US-gov-copyright is a red herring.
2018.07.30 20:03:08, replying to unknown: Let me see if I understand. You're claiming that, in Germany, you can't do a BSD-level waiver of your copyright? Or you think that BSD works but saying PD leaves you with _more_ rights? How do you explain the "Kein Schutz" German court decision quoted in http://web.archive.org/web/20140421052844/http://ig.cs.tu-berlin.de/oldstatic/sa/043?
2018.07.30 18:14:56: Puzzled by the comparative cycles/byte claims for Google's Randen (https://github.com/google/randen) on Westmere. 1.54 for Randen, ok, but 3.02 for ChaCha8? I see 1.34 for ChaCha8 generating 1536 bytes, so 1536-byte fast-key-erasure RNG (https://blog.cr.yp.to/20170723-random.html) should be well under 1.54.
2018.07.30 18:18:58: It seems to me that the 3.02 number comes from Jan Wassenberg reimplementing ChaCha8 and then reimplementing some sort of RNG on top of that, instead of reusing existing (faster) ChaCha8 stream software and fast-key-erasure RNG software from the SUPERCOP software collection.
2018.07.30 18:32:28: To be clear, I recommend ChaCha20 instead of ChaCha8. It's hard to find applications where such a fast RNG is a bottleneck. More importantly, after DES and RSA-512 and SHA-1 and Sweet32 and so on, hasn't the cryptographic community learned to stop cutting things so close?
2018.07.30 14:38:08, replying to unknown: Lawrence Rosen was spreading similar FUD about public domain in the US (http://www.rosenlaw.com/lj16.htm), but the courts disagree (see https://cr.yp.to/publicdomain.html for citations), and he later admitted that he was wrong (http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2012-March/001679.html). Does the Europe FUD have a different basis?
2018.07.29 21:16:26: New djbsort release, version 20180729: https://sorting.cr.yp.to/changes.html Rewritten avx2 code (fully supported by latest verifier), now just 7328 Haswell cycles for the int32_sort(x,1024) benchmark. Large arrays are now sorted in place. Types now supported: int32, uint32, float32.
2018.07.20 00:47:17: Slides now available from #ANTS2018 #ANTSXIII rump session: https://ants.2018.rump.cr.yp.to
2018.07.17 20:40:24, replying to "Vlad Krasnov 💪🇺🇦 (@thecomp1ler)": Thanks for the information. https://sorting.cr.yp.to/refs.html now has a link. Do I correctly understand that the paper was in 2016 and the code release was in 2017? I have a PIC port of your code doing n=1024 in about 20000 Haswell cycles; does this match the speed that you expect?
2018.07.17 18:53:54: New djbsort release, version 20180717: https://sorting.cr.yp.to/changes.html Verification now handles all five int32 implementations (avx2, portable1, portable2, portable3, portable4). API now provides both int32_sort and uint32_sort.
2018.07.15 01:46:49, replying to "Vlad Krasnov 💪🇺🇦 (@thecomp1ler)": Thanks for the reference. There are vectorized sorting networks in the literature as far back as 1987; see https://sorting.cr.yp.to/refs.html. People use these on GPUs. But the conventional wisdom has been that other sorting algorithms are faster on typical CPUs.
2018.07.14 19:11:00: "Sorting integer arrays: security, speed, and verification." Slides for first djbsort talk now available: https://cr.yp.to/talks.html#2018.07.11
2018.07.12 08:02:29, replying to "HackerCow (@HackerC0w)": I always thought pull requests were the killer github feature! But the github terms are problematic. The source is in a local git repo, and git->web exists, but I run apache etc. only for low-security sites. Does anyone have good tools for sequence of tarballs->static web pages?
2018.07.11 09:44:36, replying to "Questor/Inter (@questorInter)": The fast sorting code (what people will put into applications) is public domain. On the verification side, angr and valgrind are GPL, and my parts on top are public domain.
2018.07.11 01:07:39: First release of djbsort: super-fast constant-time automatically verified AVX2 sorting code for int32 arrays. https://sorting.cr.yp.to (Next target is ARM NEON.) Verification starts with the #angr toolkit for symbolic execution, which in turn uses libVEX from Valgrind.
2018.06.15 17:09:13, replying to "Chris Peikert (@ChrisPeikert)": What precisely do you claim needs to be "corrected" in the tweet? Do you not understand the meaning of the first two words ("Sounds like")?
2018.05.26 13:50:07: Sounds like yet another attack exploiting PKE/KEM decryption failures: https://groups.google.com/a/list.nist.gov/forum/#!topic/pqc-forum/Hr2mTEW0nRo Certainly won't be the last decryption-failure attack. This attack is an example of decryption-failure question #2 from the original version of the NTRU Prime paper posted in 2016.
2018.05.26 14:07:56: It's fascinating to look back at some dangerously overconfident responses to the paper, such as "There is abundant literature on CCA2-secure encryption/KEM from LWE problems, which in particular prevents attackers from triggering decryption failures in the sense described here".
2018.05.22 17:38:13, replying to "Rens van der Heijden (@namnatulco)": Thanks. Now linking to local copies.
2018.05.22 17:27:10, replying to "Alex Biryukov (@alexcryptan)": Are you able to run inside a Xen VM (or multiple Xen VMs), not touching dom0? For example, are you developing on EC2? The first whibox code depended on VirtualBox, and in my sysadmin's hat I much prefer Xen.
2018.05.18 14:41:07, replying to "Matthew Green (@matthew_d_green)": Internally, libpqcrypto has some support for X25519 (labeled "notpq"). There are many obvious ways to provide hybrids at various layers, and we're still deciding which options are best. Anyway, other libraries are welcome to copy the safe interface design.
2018.05.18 13:26:12, replying to "Matthew Green (@matthew_d_green)": libpqcrypto (https://libpqcrypto.org) includes a simple command-line interface designed to prevent common security failures: everything aims for CCA2, verification failures produce empty output in case errors are ignored, etc. But still needs consttime + tons of security review.
2018.05.14 15:34:12, replying to "Olivier 🐿️ (@gloupin)": Thanks. I skipped past NTS-KEM since they said they were abandoning the patents, but you're right that I should list the patent numbers explicitly for future reference.
2018.05.14 03:16:12: Have extended https://cr.yp.to/patents.html to try to list all numbers of patents+applications mentioned in the #NISTPQC IP statements. Noticeable risk of some numbers being missed or garbled. Would appreciate confirmation from someone else going independently through the statements.
2018.05.14 01:52:09: Looks like 34 different patents (or applications) mentioned in 19 #NISTPQC submissions, including broken Compact LWE, DME, WalnutDSA and some-params-broken RLCE. This doesn't mean that the other 70% of the submissions are safe: a few important patents affect multiple submissions.
2018.05.14 02:02:16: Some patent applications aren't published yet so evaluating their impact this year will be difficult. For example, there seem to be six applications regarding two LWR/RLWR submissions (Lizard and Round2), and for the moment we have no way to tell whether Saber is also covered.
2018.05.12 03:21:20: Alert: There's a patent on noisy DH+reconciliation with priority date 2010.02.18: https://patents.google.com/patent/EP2537284B1/en. Preliminary assessment is that this covers many lattice-based and some code-based #NISTPQC submissions. Even worse mess than the Ding patent.
2018.05.08 17:46:26: NIST posts scans of the patent statements from all #NISTPQC submitters: https://csrc.nist.gov/projects/post-quantum-cryptography/round-1-submissions Now community has to figure out which patents apply to which submissions. Of course we also have to watch out for submarine patents from non-submitters, but this is a great start.
2018.05.08 15:19:55: Picking up my mail from @TheUPSStore: Mailbox is full, mostly from a huge catalog addressed to a different name at a different mailbox. Some mail is clearly missing. Store admits it discards mail. I've probably handed back hundreds of misdelivered letters but this is impressive.
2018.05.07 00:22:29: Have spent the last hour and a half on the phone with @united, with no useful results so far. Most of the time has been on hold, often with no explanation. Is the United agent trying to handle multiple calls in parallel?
2018.05.02 09:33:54: Ran Eurocrypt 2018 rump session with @hyperelliptic. Turns out to be difficult to kick people off stage in Israel when they go over time; thanks to RMA, JH, EL, SP, and HS for their assistance. Slides from the talks are now available: https://eurocrypt.2018.rump.cr.yp.to
2018.05.01 07:49:05, replying to "Luca De Feo (@luca_defeo)": Running to the max on each exponent sounds like an easy way to be constant-time, at the expense of a 2x slowdown. Atomic blocks would be faster and would leak only the total length of the computation, which could be chosen to be constant.
2018.04.30 06:25:45, replying to "Frédéric Grosshans (@fgrosshans)": And how do you define "communication channels" without making ad-hoc references to QKD? How does your definition exclude a trivially "secure" solution where A&B send random garbage through the "communication channels" and, separately from that, have a pre-shared secret key?
2018.04.23 02:00:11, replying to "Frédéric Grosshans (@fgrosshans)": Are you capable of defining your concept of security for exchanged keys _without_ making ad-hoc references to the particular structure of QKD as part of the definition?
2018.04.22 03:43:04: Good: https://eprint.iacr.org/2018/354.pdf adds OpenSSL as another deployment option for crypto software providing the NaCl/SUPERCOP/TweetNaCl/libsodium/HACL*/libpqcrypto API. Bad: Same paper describes OpenSSL as the only way to be "deployed", "mainstream", "real-world", "practice-driven".
2018.04.21 13:00:52, replying to "Frédéric Grosshans (@fgrosshans)": So you think that "absolute security" of an exchanged key means that it's safe against all attacks, but crossing out the word "absolute" means that it's referring only to attacks intercepting the photons in the particular key-exchange protocol you have in mind?
2018.04.14 20:48:54, replying to "Farce Majeure🌹 (@vathpela)": Supposedly Microsoft is filing with NIST some sort of release of a 2003 patent that might otherwise apply to SIKE. NIST required each submission to file patent claims/disclaimers this week; please check the scans once they're posted and ask on pqc-forum about anything unclear.
2018.04.13 21:55:56, replying to "Frédéric Grosshans (@fgrosshans)": So you think that crossing out the word "absolute" would change the meaning of the claim that QKD exchanges "a cryptographic key between two remote parties with absolute security, guaranteed by the fundamental laws of physics", so it would no longer be clearly false advertising?
2018.04.13 21:41:46: Quite a bit of discussion at #NISTPQC of staying safely away from patents on post-quantum crypto. Various submitters emphasize they're patent-free. Microsoft says it's giving up a potentially relevant 2003 patent. NIST is collecting patent statements and will post them soon.
2018.04.12 05:55:20, replying to "Frédéric Grosshans (@fgrosshans)": Consider the statement that QKD exchanges "a cryptographic key between two remote parties with absolute security, guaranteed by the fundamental laws of physics". This statement communicates false information to the reader. Are you claiming that this depends on "broader context"?
2018.04.08 08:53:48, replying to "Frédéric Grosshans (@fgrosshans)": Let me see if I understand. A reader in your world, facing a statement that clearly says X, goes reading through the entire paper that contains the statement to figure out whether there are admissions that X isn't actually true, and then reinterprets the statement accordingly?
2018.03.31 20:46:37, replying to "Frédéric Grosshans (@fgrosshans)": So you're agreeing that the 2016 claim of QKD security being "guaranteed by the fundamental laws of physics" is wrong, but you're saying that the 2015 claim of QKD security being "guaranteed by the laws of physics" means something different and correct?
2018.03.31 20:52:42: And your non-literal reading of the text has nothing to do with (undefined) distinctions (having no obvious relevance) between "laws of physics" and "fundamental laws of physics", but instead relies on admissions that the authors have made elsewhere?
2018.03.29 19:38:49, replying to "Frédéric Grosshans (@fgrosshans)": To be clear: You're saying that for decades the QKD community hasn't been making claims like "QKD as a cryptographic primitive offers security that is guaranteed by the laws of physics"? (To answer your question, the "law of Nature" quote I gave was from https://arxiv.org/abs/quant-ph/9504002.)
2018.03.27 23:04:28, replying to "mjos\dwez (@mjos_crypto)": The internal C functions are documented in https://ntruprime.cr.yp.to/software.html. Reference implementations in Sage are at the top of the page. There's also a detailed spec saying mathematically what everything does. People too obtuse to find any of this are not encouraged to look at the code.
2018.03.27 21:46:36, replying to "mjos\dwez (@mjos_crypto)": You've previously copied various crypto_aead_* functions from https://bench.cr.yp.to/supercop.html, and now you're trying to benchmark various crypto_sign_* and crypto_kem_* functions, but you claim to "have no clue what 'crypto_hash_sha512.h' is"?
2018.03.27 14:46:21, replying to "Frédéric Grosshans (@fgrosshans)": Let me get this straight. You're agreeing that the quote I gave (from a 1995 QKD paper, no erratum ever issued) is falsely claiming QKD unbreakability, but you're claiming that for decades now the QKD community _hasn't_ been claiming QKD unbreakability?
2018.03.25 01:52:23, replying to "Frédéric Grosshans (@fgrosshans)": When people write papers claiming, e.g., that QKD "offers the ultimate security of the inviolability of a law of Nature for key distribution", are you saying that this isn't a claim that QKD is unbreakable? Or are you saying that these people aren't part of the QKD community?
2018.03.23 22:37:56, replying to "Tancrède Lepoint (@Leptan)": I've set up a mailing list now: send email to libpqcrypto-subscribe@list.cr.yp.to.
2018.03.23 18:05:13, replying to "Jonathan Oppenheim (@postquantum)": A black hole is a very strong potential well. Your naive belief that this hides information is wrong: see Hawking radiation, horizon fluctuatons, etc. The holographic principle says that all information in a volume of space is encoded on a faraway boundary.
2018.03.23 18:10:15: If you naively think you can hide inside a black hole (or a less extreme potential well) and roll quantum dice to fill up the space around you with new random numbers hidden from the outside, you're wrong. See Bekenstein's entropy bound.
2018.03.23 18:18:05: QKD proponents claim that the security of QKD is guaranteed by the laws of physics. What we see throughout this Twitter thread is proponents switching to weaker claims (yes, there's leakage, but _hopefully_ hard to invert) without admitting that the original claim is bullshit.
2018.03.23 18:29:50: Examples of leakage already admitted in this thread: femtosecond transients; X-rays; neutrinos; gravitational waves. And then there are the corpses of "secure" QKD systems broken by Makarov et al., and the holographic principle giving a theoretical framework for QKD breakability.
2018.03.23 18:38:42: Even when QKD proponents admit that they're switching from zero-interaction claims to (hopefully-)small-interaction claims, they go back to putting the unjustifiable zero-interaction bullshit into their followup papers and grant proposals.
2018.03.23 02:28:44, replying to "Frédéric Grosshans (@fgrosshans)": And you claim that these issues disappear when the gaps are atomic-scale? Where can I find a theorem that derives your claimed QKD non-leakage from the laws of physics without _assuming_ non-leakage? And how do you explain the evident contradiction with the holographic principle?
2018.03.23 00:30:38, replying to "Frédéric Grosshans (@fgrosshans)": The paper goes far beyond your characterization, as illustrated by, e.g., the paper's analysis of "the widespread misconception that the shielding is exponential" in the gap size etc.
2018.03.22 23:53:42, replying to "Frédéric Grosshans (@fgrosshans)": Cages and shields are _not_ the same thing (see, e.g., https://people.maths.ox.ac.uk/trefethen/chapman_hewett_trefethen.pdf), and cages make the general QKD security issues easier to visualize. The bigger problem in this discussion is the constant switching from one bullshit claim to another.
2018.03.22 23:27:09, replying to "Frédéric Grosshans (@fgrosshans)": Show me any allegedly "thick enough" EM shield and I'll show you a (very expensive) detector array that sees through the shield. You'll then switch to another bullshit example without admitting you were wrong, the same way that you've switched away from the Faraday-cage example.
2018.03.22 20:31:02, replying to "Frédéric Grosshans (@fgrosshans)": You're focused on how electrons rearrange themselves on the Faraday-cage boundary to interfere with a static measurement mechanism. You're inexplicably blind to the EM wave created by exactly this motion of electrons, a wave measurable by EM sensors on the other side.
2018.03.22 20:53:54: Suppose an attacker presents you with an audiotape of the music that your electrons are communicating. You average the audiotape over time and notice that the average is 0. Do you then insist that there's no music on the tape?
2018.03.22 18:16:31, replying to "Jonathan Oppenheim (@postquantum)": Do you understand the mathematical difference between a static field (a vector at each point in space) and a dynamic field (a vector at each point in space and each moment in time)? Motion of an electron inside the cage sends out an EM wave visible outside the cage.
2018.03.22 17:39:03, replying to "Jonathan Oppenheim (@postquantum)": Why do you keep trying to weasel out of finishing the Faraday-cage analysis? Is it because you're starting to realize how stupid your "cancel EM waves" claim was, and you don't want to admit it? Actually _understanding_ the Faraday example would help you with other examples too.
2018.03.21 22:33:07, replying to "Jonathan Oppenheim (@postquantum)": So you're claiming that a Faraday cage blocks magnetic fields? What precisely is the physical mechanism by which you imagine that this happens?
2018.03.21 18:25:52, replying to "Jonathan Oppenheim (@postquantum)": I guess we have to start even more basic. My buddy walks up to a Faraday cage with a magnet and waves it around the outside, not touching the cage. Do you claim that I can't see this on my recordings from EM sensors inside the cage?
2018.03.21 17:53:38, replying to "Jonathan Oppenheim (@postquantum)": You claimed that Faraday cages "cancel EM waves". I keep asking what this is supposed to mean mathematically, and you keep dodging. Do you claim that an EM sensor inside a cage can't detect a lightning bolt hitting the cage from the outside? How about sensor outside, bolt inside?
2018.03.21 05:04:33, replying to "Aram Harrow (@quantum_aram)": The moment after impact, electrons are moving from the point of impact along the boundary of the cage. Do you claim that the electric and magnetic fields inside the cage are zero? If not, what do you claim the mathematical meaning of @postquantum's "cancel EM waves" claim is?
2018.03.17 18:29:20, replying to "Jonathan Oppenheim (@postquantum)": So you think that EM variations at the boundary of a Faraday cage are tied to EM variations inside but independent of EM variations outside? Can you please maintain the intellectual discipline to focus on resolving this dispute instead of burying it under a flood of red herrings?
2018.03.17 19:50:37: Concretely, suppose a lightning bolt hits a Faraday cage from the outside. Q1: Do you agree that this induces motion of electrons along the boundary of the Faraday cage? Q2: Do you agree that this motion of electrons is visible to an EM sensor on the inside of the Faraday cage?
2018.03.21 04:10:47: To review: @postquantum instantly comments on my paper, and as part of this he claims that Faraday cages "cancel EM waves". When I ask whether he agrees that a lightning bolt hitting the cage makes electrons move, visible to an EM sensor, he's silent for four days and counting.
2018.03.15 20:59:22, replying to "Jonathan Oppenheim (@postquantum)": If you understand the Faraday-cage example then you can't possibly believe that you're accurately characterizing my paper (let alone the holographic principle!). Let's focus on resolving the Faraday-cage dispute first.
2018.03.15 20:40:23, replying to "Jonathan Oppenheim (@postquantum)": Mathematically, what do you mean with your claim that Faraday cages "cancel" EM waves? (I think you're massively confused, and focusing on the Faraday-cage example will help pinpoint the source of confusion.)
2018.03.14 23:50:02, replying to "Jonathan Oppenheim (@postquantum)": Let me get this straight. Are you claiming that Faraday cages have a security property guaranteed by the laws of physics? If so, what precisely do you claim that this security property is?
2018.02.08 19:01:47, replying to unknown: Verification strategy for this type of sorting code for one input length: symbolically execute the code to build DAG of min-max operations; scan the DAG to find merging networks; verify each merging network using a standard linear-size set of inputs with a completeness theorem.
2018.02.08 18:53:55, replying to "Allan MacKinnon (@pixelio)": This is int32_sort_avx2(int32 *x,long long xlen). Works for any xlen; constant time for each xlen. I've seen previous AVX2 sorting networks for specific small xlen but nothing competitive for larger xlen such as 1000 (or 1000000). Of course people use sorting networks on GPUs.
2018.02.08 17:11:35: 10000 Haswell cycles to sort 1024 32-bit integers: 13x faster than radix sort in Intel's Integrated Performance Primitives library, 2.6x faster than sorting code from NTRU Prime paper. Working on formal verification.
2018.02.05 17:37:05: After #Meltdown and #Spectre, has anyone built an HVM (rather than PV) version of xen-create-image from xen-tools? Or, maybe more useful, a PV-to-HVM converter smart enough to handle a VM created by xen-create-image? Did some searches but haven't found anything functional yet.
2018.02.05 00:30:51, replying to "Paulo Barreto (@pbarreto)": Simon says the f computation is made "reversible (and hence unitary) at the cost of only a constant factor in the number of computation steps". He's talking about a computation with steps (and time), following the definitions in Section 2. An oracle call doesn't have steps.
2018.02.04 23:31:39, replying to "Paulo Barreto (@pbarreto)": Fourier-twice does not call an oracle. It is a QTM (as Simon says explicitly), not an oracle QTM. Its time (which Simon states explicitly) is the time for the reversible f computation created by Lecerf--Bennett (as Simon states explicitly) + linear algebra, with no oracle calls.
2018.02.04 23:33:59: Simon is completely explicit when he switches to the oracle version in Section 3.2 ("Relativized Hardness of our Problem"). Section 3.1 is the real algorithm (in particular for poly-time f, which he highlights), and Section 3.2 has a random oracle (which can't be poly-time).
2018.02.04 23:44:13: Simon says that the "computation of (x,f(x)) from x in time T_f(n) in step 2" of the real algorithm can be made "reversible (and hence unitary) at the cost of only a constant factor in the number of computation steps". If f were an oracle (it isn't!) then this would be nonsense.
2018.02.04 22:29:52, replying to "Paulo Barreto (@pbarreto)": Read Simon's paper. 1. This isn't an oracle: it's the output of the Lecerf--Bennett conversion, a series of quantum gates. 2. The stated time counts these individual gates. 3. The whole algorithm is a "QTM", which by definition (see Section 2) is a composition of quantum gates.
2018.02.04 22:34:06: "In this paper, we present an expected polynomial-time algorithm for a quantum computer that distinguishes between two reasonably natural classes of polynomial-time computable function." No oracles here. Simon treats the oracle version separately and labels it explicitly.
2018.02.04 22:19:56, replying to "Paulo Barreto (@pbarreto)": Kuwakado and Morii need the legitimate Even--Mansour user to be running a quantum computer that reveals ciphertexts for attacker-specified superpositions of plaintexts. Johansson and Larsson need the user to be screaming "Look, attacker, here's my key!" There's no threat here.
2018.02.04 21:58:15, replying to "Paulo Barreto (@pbarreto)": You're confused. Simon's algorithm is a complete explicit quantum computation, without any oracles. This is exactly what makes the algorithm work on a quantum computer (unlike the algorithm you've been citing). The complexity that he states is the number of quantum gates he uses.
2018.02.04 21:31:19, replying to "Paulo Barreto (@pbarreto)": This is "print s" rephrased in one useless way after another. Simon's accomplishment is much more interesting: an efficient, explicit conversion of (1) a size-T _circuit for f_ into (2) a size-O(T+poly) Hadamard/Toffoli composition that _computes s_.
2018.02.04 17:39:41, replying to "Jan-Åke Larsson (@JanAAkeLarsson)": Do you continue to claim that "Simon's paper is completely within the oracle paradigm"? The claim is simply not true. Simon gives an explicit and efficient conversion from a time-T circuit for f into a time-O(T+poly) quantum circuit to find the period s.
2018.02.04 13:23:56, replying to "Jan-Åke Larsson (@JanAAkeLarsson)": "Simon's paper is completely within the oracle paradigm": Not even close. Here's the paper: http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.51.5477&rep=rep1&type=pdf Section 3.2 studies an oracle, but this is after a _real_ algorithm (Simon's algorithm!) appears in Section 3.1, using the real computational model in Section 2.
2018.02.04 12:38:18, replying to "Niklas Johansson (@Niklas_Skans)": Simon's algorithm is presented in Section 3.1 of Simon's paper and is completely explicit, invoking a Lecerf/Bennett subroutine to efficiently convert a time-T_f circuit for f into a time-O(T_f) quantum circuit for f. It has no oracles and no other cheats.
2018.02.04 12:08:02, replying to "Paulo Barreto (@pbarreto)": 6a computes s using U_f. 6b constructs U_f using U_s. 7 constructs U_s using v, which is defined in terms of s. Useless. The circularity is obfuscated through abstraction and uninstantiated generalization: if you had a different construction of U_f then you could use it instead.
2018.02.04 12:14:32: For comparison, Simon's paper starts from a fast conventional circuit to compute f. It explicitly and efficiently builds a composition of Hadamard and Toffoli gates that quickly computes s. As soon as we have enough Hadamard and Toffoli gates, we can actually run this algorithm.
2018.02.04 02:32:52, replying to "Paulo Barreto (@pbarreto)": The only construction of a "Simon" oracle in this paper is a trivial encoding of the period s. For comparison, Simon's paper efficiently converts a small conventional circuit for f into a small composition of Hadamard and Toffoli gates to compute s, _without_ having s as input.
2018.02.04 02:26:44, replying to "Niklas Johansson (@Niklas_Skans)": Can you tell us the period of the function mapping an integer x to 2^x mod 2^12345-3? Shor (generalizing Simon) can, given enough fast reliable Hadamard and Toffoli gates.
2018.02.04 02:21:52, replying to "Niklas Johansson (@Niklas_Skans)": Your obfuscation has deceived people regarding the performance of the (useless, trivial) algorithm that you published. Whether you can come up with a fast ad-hoc algorithm for any particular special case is irrelevant.
2018.02.04 02:54:10: Simon's algorithm, as presented in Simon's paper (Section 3.1), is constructed explicitly and efficiently from an f circuit. You can't claim to have a replacement for Simon's algorithm if your construction needs extra inputs that you have no idea how to compute efficiently.
2018.02.04 01:08:16, replying to "Paulo Barreto (@pbarreto)": The claimed simulation (of Simon's method on a non-quantum computer) cheats by asking the user to provide the period as input. For an earlier and more general cheat see "trapdoor simulation" in https://cr.yp.to/talks.html#2015.04.03. Useful for verification but not for actual computations.
2018.02.04 00:44:41, replying to "Niklas Johansson (@Niklas_Skans)": You don't have an explicit fast construction _where the input to the construction is a fast circuit for f_, correct? You need an extra input (basically s), or a massive slowdown (unless f has some special structure making it easy), right?
2018.02.03 23:51:34, replying to "Niklas Johansson (@Niklas_Skans)": Simon's method (Section 3.1 of Simon's paper) is an explicit construction of a quantum circuit using expected time "O(n T_f(n) + G(n))" to find the n-bit period s of f; T_f is the time to compute f; G is linear-algebra time. You don't have an explicit fast construction, right?
2018.02.03 22:28:46, replying to "Niklas Johansson (@Niklas_Skans)": If I show you a small circuit to compute f, how long will it take you to show me a small QSL black box suitable as input to your algorithm? The only answer I see in your paper is to first compute s (presumably by Simon or a very slow non-quantum computation). Any better answer?
2018.02.03 21:52:11, replying to "Niklas Johansson (@Niklas_Skans)": So you're saying that, for a user to run your algorithm and find the period s (or to find whether s exists), the user needs to provide an input that exists but that you don't claim any efficient method to find (basically, an obfuscated encoding of s). Did I get this right?
2018.02.03 21:18:24, replying to "Niklas Johansson (@Niklas_Skans)": I start with a (quick) conventional circuit to compute f. I then feed this circuit to Simon's method, which (quickly) outputs a composition of Toffoli and Hadamard gates to (quickly) compute the period s. Your Simon replacement has a different data flow, taking s as input, right?
2018.02.03 20:53:28, replying to "Niklas Johansson (@Niklas_Skans)": Your Simon-replacement algorithm is defined in terms of the v's, which are defined in terms of the period s, right? How is the user supposed to find s in the first place? Simon's method gives a uniform constructive quantum answer to this, whereas your replacement sounds useless.
2018.01.26 22:58:29: Superficial demands for every crypto paper to have a proof (e.g., quoted in https://cr.yp.to/talks/2016.03.09/slides-djb-20160309-a4.pdf; search for "trivial") remind me of superficial demands to have documentation for each function in a program. Sounds good, but sets up bad incentives.
2018.01.26 22:48:49, replying to "Brian Smith (@BRIAN_____)": Many alternatives were proposed (e.g., by Microsoft). The email records show tons of technical analysis of the options, explicitly downplaying Curve25519 deployment. If you think the technical criteria were misevaluated or badly weighted, please send technical comments to CFRG!
2018.01.26 14:14:46, replying to "bmastenbrook-deactivated-41902 (@bmastenbrook)": The literature has attacks that slice right through your "minimal protection". The literature also has much better defenses. You're being fooled by a marketing stunt.
2018.01.14 08:20:59: There are more than a billion ARM Cortex-A7 devices: https://web.archive.org/web/20160903230223/http://www.arm.com:80/products/processors/cortex-a/cortex-a7.php ARM and Raspberry Pi say these are invulnerable to #Meltdown and #Spectre: https://developer.arm.com/support/security-update https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/ If this is wrong then lots of people need to know.
2018.01.12 22:16:44, replying to "Deirdre Connolly¹ (@durumcrustulum)": The claim of a bug in NaCl's Curve25519 implementation is completely incorrect. That code was never part of any NaCl release---precisely because it never passed NaCl's stringent review process.
2018.01.12 22:18:38: The Curve25519 code that's actually in NaCl, including the assembly code, _did_ pass NaCl's review process, and has also passed various followup verification and validation steps.
2018.01.12 22:22:01: Of course there's _massive_ value in automating manual verification procedures, but this shouldn't be accompanied by outright misinformation regarding the correctness of existing libraries.
2018.01.11 22:49:33, replying to "Murat Ursavaş (@murtikano)": No, anything that's comparing KPTI to non-KPTI is going to obscure the effect I'm wondering about.
2018.01.11 21:23:58: Even with today's ludicrously bloated kernels, I'm skeptical about the idea that speculative execution _in the kernel_ seriously helps computer performance. Has anyone measured overall slowdown from recompiling kernel branches to use LFENCE with new (fully serializing) microcode?
2018.01.10 19:03:01, replying to "Scott Arciszewski (@CiPHPerCoder)": The current steps in the process were already announced on the mailing list. My more recent update efforts were sabotaged by Google's increasingly draconian "anti-spam" systems. (The list is moving.)
2018.01.10 18:01:57: Number of https://eprint.iacr.org/2017 papers mentioning CAESAR: 59. (Including one by me.)
2018.01.10 17:32:04, replying to "Scott Arciszewski (@CiPHPerCoder)": There are 22 items in the CAESAR timeline, of which 17 are completed, the 2 most recent being July 2017. So what exactly do you mean by "stale" and "full of TBA"? And what would you expect to be communicated?
2018.01.10 17:34:52: As for NIST's post-quantum competition, quite a few of the submissions are terribly weak, which of course produced a flurry of comments. One of the reasons that CAESAR selection is difficult is that every remaining candidate seems reasonably strong.
2018.01.10 14:40:12, replying to "Joachim Strömbergson (@Kryptoblog)": Non-EM-defended circuits are vulnerable to EM attacks. This has been known for many years and has nothing to do with Curve25519. Very similar attacks apply to, e.g., NIST P-256.
2018.01.08 14:37:57, replying to "Colin Percival (@cperciva)": There have been many other secret eprint rejections. Most of the victims seem to be scared that complaining about this in public will damage their careers.
2018.01.05 16:44:31, replying to "Tony "Abolish ICE" Arcieri 🦀🌹 (@bascule)": The CAESAR submission teams received nearly 20000 words of comments (not evenly distributed; that's life), and the selection committee is waiting for responses. What precisely is your problem?
2017.12.29 15:34:00: WireGuard session at #34C3 from @EdgeSecurity remains packed, now has two bouncers outside the door.
2017.12.27 12:41:41: You can run the #LatticeHacks scripts tomorrow on your own machine if you install @sagemath (Python + lots of math libraries). Reasonably packaged in Debian (starting with stretch) and Fedora (for longer); also straightforward to install from source despite being a huge package.
2017.12.21 11:41:20, replying to unknown: CAESAR submission teams have received a total of more than 19000 words of anonymized comments and have an upcoming deadline to reply. What is your problem, precisely?
2017.12.21 05:04:09: Moving the applied-cryptographers-at-crypto, boring-crypto, cryptanalytic-algorithms, crypto-competitions, randomness-generation, and snakeoil mailing lists off Google. Google doesn't make this easy so you have to resubscribe, sorry: https://cr.yp.to/lists.html
2017.12.10 01:30:51, replying to "Adam Langley (@agl__)": Sure, but you're adding even more roughness by omitting some of the identifying information for the different CPUs involved!
2017.12.09 23:58:33, replying to "Adam Langley (@agl__)": Yet another thing: there's a big difference in speeds between, e.g., E3-1220 v2 (3.1GHz Ivy Bridge) and E3-1220 v5 (3GHz Skylake).
2017.12.09 02:51:08, replying to "Matthew Green (@matthew_d_green)": Formal definitions: same queries but now quantum computation. Engineering: same disastrous impact of giving CCA-vulnerable tools to users.
2017.12.09 03:03:05: I argued in https://blog.cr.yp.to/20161030-pqnist.html that NIST should allow CCA-vulnerable submissions _for wrapping in SIGMA_. But _users_ reusing keys need CCA security.
2017.12.09 02:36:42, replying to "Matthew Green (@matthew_d_green)": NIST properly says that key reuse requires IND-CCA2 security. This of course is not the actual definition, but it's the only safe bottom line for users.
2017.12.09 02:09:35, replying to "Adam Langley (@agl__)": Something else: There's a second KEM, ntrulpr4591761, in the NTRU Prime submission. 58756/94508/128316 Haswell cycles keypair/enc/dec.
2017.12.09 01:57:39, replying to "Adam Langley (@agl__)": Frodo leapt out at me as an example where the paper wasn't doing the extra work for CCA. Maybe the submission to NIST is different.
2017.12.09 01:43:34, replying to "Adam Langley (@agl__)": It's critical to distinguish CCA security (can reuse one key to receive many ciphertexts) from CPA security (need new keygen for every ciphertext).
2017.12.07 11:36:15, replying to "Paulo Barreto (@pbarreto)": The zero-decryption-failures theorem for NTRU Prime is now quantitatively better, allowing noticeably better speed-security tradeoffs.
2017.12.07 03:01:24: NTRU Prime submission to #NISTPQC: https://ntruprime.cr.yp.to/nist.html Submission team in Twitter-handle order: @BeingJade, @cvvrede, @hashbreaker, @hyperelliptic
2017.12.04 13:35:21: Classic McEliece https://binary.cr.yp.to/nist/mceliece-20171129.tar.gz Code-based crypto, 40-year history. Big pk, small ct, surprisingly fast. #NISTPQC submitters A-Z @cbcrypto @cryptocephaly @cryptojedi @edopersichetti @hashbreaker @hyperelliptic @ingovm @rafaelmisoczki @refezs Sendrier @TungChou1 @WenWang0
2017.12.01 20:29:21, replying to "Jacob Alperin-Sheriff 🐵 (@DemocraticLuntz)": The 82 total, 59 enc, 23 sign numbers can't be exactly right: at least one submission provides both encryption _and_ signatures.
2017.12.01 15:47:57, replying to "JP Aumasson (@veorq)": The pqRSA submission (using 1GB keys) has been online for a week as a model submission in the pqskeleton package: https://pqcrypto.org/pqskeleton-20171123.tar.gz
2017.12.01 04:27:25, replying to "JP Aumasson (@veorq)": Maybe that's because hundreds of cryptographers have been busy putting the finishing touches on their own post-quantum submissions to NIST.
2017.11.07 00:18:15: NSA says:We need a "generalist" cipher that works well everywhere, so here are 20 incompatible Simon+Speck variants. https://eprint.iacr.org/2015/585
2017.11.06 22:30:47, replying to "Halvar Flake (@halvarflake)": Main problem is Infineon deploying something insecure. Presumably exploited for years. Infineon also delayed public awareness for 9 months.
2017.11.05 05:26:22: New blog post "Reconstructing ROCA" w/@hyperelliptic: how quickly attack can be developed from a limited disclosure. https://blog.cr.yp.to/20171105-infineon.html
2017.10.23 22:11:48: Wait: @matthew_d_green named DUHK "Attack of the week" on _Monday_? Top-10-attacks-this-week judges meet on Fridays! https://blog.cryptographyengineering.com/2017/10/23/attack-of-the-week-duhk/
2017.10.23 00:34:40, replying to "Graham Steel (@graham_steel)": Yup. Our 2048bit attack using @sagemath is now 5-25% faster than ROCA blog. 3fd6a53a3b6362248ac10de4a8108df3c839a7193a96d0991c6675990599d917
2017.10.21 03:34:53, replying to "Tanja Lange (@hyperelliptic)": More exploration with @hyperelliptic has now produced working attack code: 3f5ba89d705a1059683c4c406dcda87f8af73f37cf0202cc74b875fcc28b3cb6
2017.10.17 13:24:08: New blog post "Quantum algorithms to find collisions" https://blog.cr.yp.to/20171017-collisions.html: Analysis of several algorithms for collisions and preimages.
2017.10.11 19:33:01: "Today billions of brains sit in skulls, impervious to search warrants. Warrant-proof skulls are a serious problem." https://www.justice.gov/opa/speech/deputy-attorney-general-rod-j-rosenstein-delivers-remarks-encryption-united-states-naval
2017.10.05 14:03:36: Reversible circuits/computations/algorithms/tools (quantum, low-power, etc.) mailing list: reversible-subscribe at http://list.cr.yp.to.
2017.10.05 13:52:54, replying to "JP Aumasson (@veorq)": Even in the paper's bad model, the 12/25 claim is wrong. It's actually time N^0.28, hardware N^0.24; slower+bigger than rho (N^0.27,N^0.23).
2017.10.05 13:58:44: The authors say they're counting all space, and count the N^0.20 quantum hardware, but they forget to count the N^0.24 non-quantum hardware.
2017.09.14 18:54:33: The simplicity of Curve25519 is a big part of what has enabled formally verified (HACL*) X25519 software in Firefox: https://blog.mozilla.org/security/2017/09/13/verified-cryptography-firefox-57/
2017.09.07 09:27:07, replying to "JP Aumasson (@veorq)": Looking more closely I see that the paper's cost analyses are wrong even for the non-quantum part: the usual instant-access-to-RAM mistake.
2017.09.07 09:43:45: "First proof of an actual quantum time speedup": The paper doesn't analyze actual time. For oversimplified "time", 1998 BHT proved speedup.
2017.09.07 08:38:44, replying to "Петър Дончев (@petar_donchev)": Parallel rho is from the 1990s and is already taken into account in standard symmetric-crypto sizes. The new attack has _worse_ performance.
2017.09.07 08:20:25: Collisions: https://eprint.iacr.org/2017/847 says time N^0.4 using hardware N^0.2. But parallel rho is better: time N^0.35 using hardware N^0.15.
2017.09.07 08:26:37: The new paper _also_ needs some quantum hardware (rho doesn't), and I don't see analysis of communication costs (rho has low communication).
2017.09.07 08:30:34: How does the paper portray worse performance numbers as better? By artificially limiting hardware to 1 small "processor" plus huge "memory".
2017.09.07 08:32:31: Of course most of the algorithms literature makes this mistake. But this paper makes the mistake _and_ incorrectly suggests that it doesn't.
2017.09.04 16:23:52, replying to "mjos\dwez (@mjos_crypto)": The core of the discussion is the impact of benign malleability on protocols. Elliptic curves are a standard example to illustrate the idea.
2017.08.29 08:20:11: The recommendation in https://eprint.iacr.org/2017/806 (reject some inputs to libgcrypt's variable-time code) is incompetent. System still breakable.
2017.08.29 08:29:30: The attack in the paper artificially focuses on low-order points, but variable-time code _leaks secrets_ even if those points are rejected.
2017.08.29 08:34:18: What actually stops all of these timing attacks (in the original Curve25519 paper, in NaCl, and in broad usage today) is constant-time code.
2017.08.29 08:45:38: Tools to build and verify constant-time code are becoming increasingly easy to use and increasingly convincing. Clearly the right direction.
2017.08.29 08:49:07: We have one success story after another of constant-time code. Attackers who can't break it tell us to make it more complicated? Ridiculous.
2017.08.29 09:00:55: We need the trusted crypto code base to be small enough + simple enough to convincingly verify. Unnecessary complexity interferes with this.
2017.08.28 06:20:42, replying to "Aris Adamantiadis ☠ (@aris_ada)": The paper says "my Curve25519 software is already immune to timing attacks". It doesn't say "Curve25519 is immune to libgcrypt". Nothing is.
2017.08.19 23:54:38, replying to "Mastodon: soatok@furry.engineer (@SoatokDhole)": McEliece has much more stable security story than lattice-based crypto. Tung Chou has new McBits software online: https://tungchou.github.io/mcbits/
2017.08.19 21:58:02: NTRU patent expires today. NTRU company stopped charging for it earlier this year. Now we can all stop pretending "Ring-LWE" was innovative.
2017.08.18 16:52:32, replying to "kennyog (@kennyog)": Best known RSA attacks don't fit this model. The model "proves hardness" of many trivial things. Burden is on model to demonstrate utility.
2017.08.18 15:11:35, replying to "kennyog (@kennyog)": "Inversion assumption" = "OW-CPA", so we're talking about the same basic starting point. AM09 was entirely undermined by 2009 Jager-Schwenk.
2017.08.18 14:57:38, replying to "kennyog (@kennyog)": You're asking for more than is available for, e.g., RSA. Of course one can compose key IND (the "NTRU assumption") with 1-sample Ring-LWR.
2017.08.18 14:52:48: Have extended my page tracking prior art for Panasonic patent on NTRU parameters without decryption failures: https://cr.yp.to/patents/us/7929688.html
2017.08.18 05:48:50, replying to "kennyog (@kennyog)": Streamlined NTRU Prime is deterministic and avoids decryption failures, so 2003 Dent Theorem 8 proves tight RO IND-CCA2 from merely OW-CPA.
2017.08.17 07:08:03: Unexpected spinoff of the NTRU Prime work: super-fast in-cache sorting, avx/int32_sort.c. 5x faster than Intel's sorting library for n=1000.
2017.08.17 07:07:03: Streamlined NTRU Prime 4591^761 Haswell-optimized software online too. Faster than New Hope and Kyber; less bandwidth; less attack surface.
2017.08.17 07:05:16: NTRU Prime talk at SAC tomorrow by @cvvrede. New version of paper: https://ntruprime.cr.yp.to. Joint work w/Chuengsatiansup and @hyperelliptic.
2017.07.23 19:19:39, replying to "Colm MacCárthaigh (@colmmacc)": Sure. But my point is that you're already doing a mix of miscellaneous microsecond-scale operations. This RNG is always faster than that.
2017.07.23 18:51:10, replying to "Colm MacCárthaigh (@colmmacc)": Typical RNG code (e.g., OpenSSL RAND_bytes) takes longer to generate 1 byte than a fast-key-erasure RNG takes to fill up a 768-byte buffer.
2017.07.23 18:31:26, replying to "Colm MacCárthaigh (@colmmacc)": How about benchmarking the simple secure thing first, and then seeing whether there's a real argument for doing something more complicated?
2017.07.23 18:09:26, replying to "Colm MacCárthaigh (@colmmacc)": Sure: I've used 40-gigabit Infiniband, and of course it tries hard to avoid poking the CPU. But what exactly do you think the RNG issue is?
2017.07.23 17:57:32, replying to "Colm MacCárthaigh (@colmmacc)": Refilling the buffer is a small fraction of a microsecond on one of your server cores. Linux has vastly larger continual jitter than this.
2017.07.23 15:48:38: New blog post "Fast-key-erasure random-number generators": https://blog.cr.yp.to/20170723-random.html An effort to clean up several messes simultaneously.
2017.07.19 20:21:46: New blog post "Benchmarking post-quantum cryptography": https://blog.cr.yp.to/20170719-pqbench.html News regarding SUPERCOP, and more recommendations to NIST.
2017.07.14 22:40:58: Apparently @google decided to destroy the entire crypto-competitions@googlegroups.com mailing list because someone sent a drug spam message.
2017.07.14 22:50:14: No warning before or after, as far as I can tell. Supposedly @Google offers an "appeal" process but after several searches I can't find it.
2017.06.28 23:59:38, replying to "Chris Peikert (@ChrisPeikert)": KF attacks NTRU-1-tinyfg. SS proves NTRU-1-hugefg is as strong as RLWE-1. NTRU-1-normalfg _may be_ weaker, just like RLWE-2 _may be_ weaker.
2017.06.29 00:05:44: New Hope, Kyber, etc. could be above NTRU in strength, or equal, OR BELOW. You keep falsely claiming that the last possibility can't exist.
2017.06.28 19:15:27, replying to "Chris Peikert (@ChrisPeikert)": You ignore RLWE-2 (2 samples) being maybe weaker than RLWE-1, while you complain about NTRU-1 being maybe weaker than RLWE-1. Incoherent.
2017.06.28 19:02:14, replying to "Chris Peikert (@ChrisPeikert)": "What sort of cryptosystem do you think I am?" --- "We've already established that. Now we're just haggling about the number of samples."
2017.06.28 17:59:35, replying to "Chris Peikert (@ChrisPeikert)": The NTRU cryptosystem doesn't reveal as many samples as LPR10/New Hope/etc.; i.e., NTRU stays farther away from the Arora--Ge/Ding weakness.
2017.06.28 17:34:22, replying to "Chris Peikert (@ChrisPeikert)": Peikert's "at least as hard" is bogus: e.g., the Arora-Ge/Ding attack breaks Ring-LWE for parameters where NTRU is not known to be broken.
2017.06.28 17:36:31: "Ring-LWE-based" cryptosystems such as New Hope move towards the attacked parameter space, revealing more Ring-LWE "samples" than NTRU does.
2017.06.28 17:38:16: Ring-LWE is defined to allow any number of samples, and yet typical "Ring-LWE-based" cryptosystems ignore this fact in choosing parameters.
2017.06.28 17:44:45: Even worse bait+switch: theorems relating _huge_ Ring-LWE keys to lattice problems are used to sell _small_ keys not covered by theorems.
2017.06.28 17:49:11: The bottom line is that New Hope could be weaker than NTRU, or vice versa. Peikert is overstating the theorems when he claims guarantees.
2017.06.15 00:36:22, replying to "Steve Weis (@sweis)": Many of the responses to @durov _have_ been claims of immunity, usually based on ludicrous exaggerations of the number of bribes required.
2017.06.14 23:32:09, replying to "Tony "Abolish ICE" Arcieri 🦀🌹 (@bascule)": "Security is guaranteed and is immune to govt money" is ludicrous overconfidence; not the right response to "govt money implies insecure".
2017.06.14 22:57:38, replying to "Adam Langley (@agl__)": NIST demanding 2^n preimage security for SHA3-n was always about optics (can't let SHA-2 sound better!), not any legitimate fear or caution.
2017.06.14 22:37:42, replying to "Brian Smith (@BRIAN_____)": NIST demanded 2^256 preimage security for SHA3-256 through the whole competition, then suddenly proposed dropping to 2^128 for 1.2x speedup.
2017.06.14 22:43:12: The current dispute between @agl__ and @keccakteam is about a much bigger SHA-3 speedup, namely vectorization, which NIST SP 800-185 allows.
2017.06.14 22:48:35: NIST SP 800-185 vectorizes not by changing the security level but by changing the order of processing input blocks. Breaks interoperability.
2017.06.14 22:52:34: Now @agl__ correctly observes that this fast (vectorized) function isn't SHA-3, while @keccakteam correctly observes that it's standardized.
2017.06.12 19:06:22: Coppersmith, Buhler, Gordon made big advances in NFS etc. Then they were offered money by NSA's pet company IDA. No more papers since then.
2017.06.12 19:08:17: Of course the money was packaged as lucrative job offers, which means there's nothing scandalous here, right? Nothing to worry about, right?
2017.06.12 19:11:20: And _of course_ the public community will quickly rediscover all of the attacks that Coppersmith et al. secretly discovered. We're so smart!
2017.06.12 12:14:54: I'm astonished at how casually some people are dismissing the notion that NSA bribes academics. Why wouldn't they? http://www.d.umn.edu/~jgallian/PURMweb/NSA.pdf
2017.06.12 12:22:09: The documentation shows, e.g., NSA's "sabbatical program to allow mathematicians to visit us while retaining their academic affiliation."
2017.06.12 12:27:51: The same NSA ad mentions "a few million dollars annually" ("a large portion of our technology budget"?!?) for "academic research proposals".
2017.06.10 02:12:30: I really dislike this type of "security" paper, throwing trivially avoidable speed bumps into some obsolete attacks: https://eprint.iacr.org/2017/558.pdf
2017.06.09 14:48:19: Thought experiment: Suppose SHA-3 is actually faster than SHA-2. Do any other arguments in https://www.imperialviolet.org/2017/05/31/skipsha3.html (e.g. code size) hold up?
2017.06.03 14:18:42, replying to "James Pirruccello 🌁 (@jpirruccello)": The DNS TTL was 10 minutes for a while before this. Surely the ahrefs misbehavior is another example of bad software-engineering incentives.
2017.06.03 13:19:49: Interesting new public-key cryptosystem in https://eprint.iacr.org/2017/481. Obviously can use any sparse prime 2^b-2^c-..., not just Mersenne prime.
2017.06.03 13:22:53: Encrypting only a single bit is annoying. Users really want to recover A,B from AF+BG mod p for sparse A,B,F,G. Backtracking? Coppersmith?
2017.06.03 13:39:19: Try to choose B deterministically to compress AH+B, as in Streamlined NTRU Prime? Is it safe to, e.g., force each byte of AH+B to be odd?
2017.06.03 13:40:52: Assuming A,B can be quickly recovered from AF+BG, build a standard KEM by hashing (A,B) etc. Particularly clean (Dent) for deterministic B.
2017.06.03 13:49:18: Can also try to imitate other code-based/lattice-based constructions, e.g. LPR. An error-correcting code for M allows correcting M+AF-BG.
2017.06.03 13:51:58: Can also try to prove that F/G mod p is indistinguishable from uniform, as in Stehle--Steinfeld, assuming that F and G have enough bits set.
2017.06.03 13:54:54: Needless to say, nobody should be relying on any of this for security unless and until parameters survive years of thorough cryptanalysis.
2017.06.03 12:36:40: We built two shiny new servers for web service. Changed DNS records. A day later http://ahrefs.com is still pestering the old servers.
2017.05.03 11:02:27, replying to "Nadim Kobeissi (@nadim@symbolic.software) (@kaepora)" = "Nadim Kobeissi (@kaepora)": You really should take the time to carefully read @trevp__'s message. He is talking about _confusion re DH semantics_ breaking _security_.
2017.05.01 10:06:13: Paper+code now available for multiquad lattice attack (Bauch, @hashbreaker, @hdevalence, @hyperelliptic, @cvvrede): https://multiquad.cr.yp.to
2017.04.29 09:32:33: Uses fewer logical qubits than Shor; heuristically asymptotically breaks RSA faster than NFS: https://eprint.iacr.org/2017/352 Bernstein-Biasse-Mosca
2017.04.28 22:49:13, replying to "Scott Arciszewski (@CiPHPerCoder)": No. What's implemented is Shoup's "Simple RSA", aka "RSA-KEM". The session key is a hash of a fully random plaintext as long as the modulus.
2017.04.28 18:45:06: First attempt to merge the schedules of the Eurocrypt 2017 affiliated events into something usable: https://cr.yp.to/2017-eurocrypt/index.html #ec2017merge
2017.04.20 16:35:56: Worried about new assumptions like Ring-LWE? Try post-quantum RSA: https://cr.yp.to/papers.html#pqrsa by @hashbreaker+@nadiaheninger+@paulslou+@ltv511
2017.04.15 14:31:08: What really bugs me about all this "Windows is vulnerable" news is the notion that it wasn't continuously vulnerable from 1985 through 2017.
2017.04.15 14:22:03: CurveCP's zero-padding (https://curvecp.org/messages.html) was designed years before http://ringroadbug.com, explicitly to stop that type of attack.
2017.04.15 00:00:39: Post-quantum cryptography, new introductory paper aimed at general science audience: https://eprint.iacr.org/2017/314.pdf by @hashbreaker, @hyperelliptic
2017.04.11 13:19:16: Proposed law re @united, part 1: Airlines _must_ call for volunteers. No more "involuntary". No exceptions. They overbooked; they pay.
2017.04.11 13:19:43: .@united Proposed law, part 2: Airlines must pay volunteer in clear rebooking+cash or clear cancellation+cash. No more deceptively labeled vouchers.
2017.04.11 13:20:28: .@united Proposed law, part 3: Airlines must pay $100/hour to each delayed passenger. Delay is measured by when door is opened at the destination.
2017.04.11 13:20:52: .@united Part 3 is important because otherwise airlines have too much incentive to drag out the volunteering process for hours. Who wants $1?... $2?
2017.04.11 13:21:18: .@united Finally, name passenger-rights law after the poor guy beaten up by @united, in the hope that the airlines never forget why the law exists.
2017.04.10 01:01:15, replying to "Tavis Ormandy (@taviso)": Somewhat harder exploits => less frequent news about exploits => less panic => less funding for _real_ solutions. Not clear this is a win.
2017.03.27 00:03:15, replying to "Alexander Klink (@alech)": Thanks for the data. How he was advertising the drops is one of the open questions here. Was he also taking them himself?
2017.03.27 00:05:09: Another open question is what the eye drops actually were: "irritant"? "anti-irritation"? Maybe different over the years?
2017.03.27 00:07:13: It's sad that I have to recuse myself from judging this: the investigation could actually have been quite interesting. :-)
2017.03.26 23:55:49: SHA-256 commitment: f579fc93992c08b968b4d373ced164cb2623a136022c78ccf9ef87c3185d48c1
2017.03.26 17:27:17, replying to "Democratic Gremlin iz @Teelin@det.social 🌻 (@Teelin)": The @TUeindhoven rules generally _allow_ complaints straight to the central committees. But step-by-step is encouraged. @stonehead
2017.03.26 13:10:52, replying to "Democratic Gremlin iz @Teelin@det.social 🌻 (@Teelin)": You're fabricating claims that I never actually made. @stonehead @TUeindhoven
2017.03.26 00:48:49, replying to "badidea 🪐 (@0xabad1dea)": Your complaint relies on a serious misrepresentation of a legitimate question that Mr. de Valence has to answer.
2017.03.25 19:41:35: SHA-256 commitment: ed03c3fd4158087de9958dd8d35310cec60c88a34691c852527957efd508fd80
2017.03.24 19:11:56, replying to "Wim Remes 🐀 (@wimremes)": This isn't a question of intent. You seem to think that I didn't follow procedures; I don't see your basis for this.
2017.03.24 19:04:12, replying to "Wim Remes 🐀 (@wimremes)": Did you miss the part where Mr. de Valence was reporting his view as "yeah, whatever" with a dismissive hand wave?
2017.03.24 18:37:22, replying to "Wim Remes 🐀 (@wimremes)": There are many applicable laws; I'm reasonably sure I followed all of them. What "situation" are you talking about?
2017.03.24 18:29:00, replying to "Dan P (@copumpkin)": I don't understand Mr. de Valence's behavior. I would very much like to hear his answers to my questions about it.
2017.03.24 18:20:05, replying to "Wim Remes 🐀 (@wimremes)": Huh? "I pointed out various problem-resolution options, including ombudsmen and mediators." He showed no interest.
2017.03.24 18:10:44, replying to "Johannes Ziemke (discordianfish.yaml) 🌐 (@discordianfish)": A "misunderstanding"? Did you read the email that _he_ linked to from his (bogus) claim that I "cut off communication"?
2017.03.24 17:59:41, replying to "Wim Remes 🐀 (@wimremes)": You seem to believe that I did something procedurally improper. Can you please identify what you think that thing is?
2017.03.24 17:32:14, replying to "Johannes Ziemke (discordianfish.yaml) 🌐 (@discordianfish)": Let's try an example: search for "cut off" in my post. Do you not agree that his claim here is obviously, verifiably false?
2017.03.24 17:11:54, replying to "Johannes Ziemke (discordianfish.yaml) 🌐 (@discordianfish)": No. A large part of what @hdevalence posted is already clearly disproven by public documents. Did you read my post?
2017.03.24 09:47:31, replying to "iang (@iang_fc)": What @hdevalence has posted is an outrageous pack of outright lies and insinuations about me. I will _not_ stay silent about this.
2017.03.24 02:38:18, replying to "Dan P (@copumpkin)": His _discomfort_ seemed quite serious, and I don't think it was made up. You're confusing different accusations.
2017.03.24 02:02:19, replying to "Rich Felker (@RichFelker)": You accused _me_ of "enabling/defending" Mr. Appelbaum in the past. What are you talking about? Don't try to weasel out of this.
2017.03.24 01:42:59, replying to "Rich Felker (@RichFelker)": I'm confused. Precisely which actions do you believe I've taken that can be honestly called "enabling/defending" Mr. Appelbaum?
2017.03.24 01:40:42, replying to "badidea 🪐 (@0xabad1dea)": He also refused to file complaints with me, and with the univ complaints committee. Now goes public, pretending he was ignored. @0xabad1dea
2017.03.24 01:31:37, replying to "BjarniBjarniBjarni (@HerraBRE)": The length was needed given the number of relevant facts to report. Responding point-by-point forced some repetition.
2017.03.24 00:37:44: Let me be clear. @hdevalence is engaging in a smear campaign against me. I am posting the information needed to clearly counteract his lies.
2017.03.24 00:35:22, replying to "Rich Felker (@RichFelker)": You think that, in defending _myself_ against a smear campaign, I'm "enabling" or "defending" Mr. Appelbaum? Please clarify.
2017.03.23 19:41:32, replying to "Rich Felker (@RichFelker)": You're making a fool of yourself. Some of the claims from @hdevalence don't even survive a check against the email he dumped.
2017.03.23 19:38:07, replying to "Rich Felker (@RichFelker)": Did you read? @hdevalence has stated many things (and implied/insinuated many more) that are objectively, verifiably false.
2017.03.23 16:49:01: Did you hear the alternative facts from @hdevalence last week? Let's now take a look at the _actual_ facts: https://eindhoven.cr.yp.to/false-statements-by-henry-de-valence.txt
2017.03.23 16:53:06: By the way, just in case anyone has missed the last few months of news, "alternative facts" are not facts. https://en.wikipedia.org/wiki/Alternative_facts
2017.03.07 10:42:23: Happy to announce that 20-author ECRYPT-CSA "Challenges in Authenticated Encryption" white paper is available from https://chae.cr.yp.to.
2017.01.27 23:11:11, replying to "Chris Peikert (@ChrisPeikert)": You're missing the extraction step, the large q/noise, and the definition of NIKE: i.e., every essential element of my tweet. @ChrisPeikert
2017.01.27 23:07:07, replying to "Chris Peikert (@ChrisPeikert)": You're missing the extraction step, the large q/noise, and the definition of NIKE: i.e., every essential element of my tweet.
2017.01.17 14:52:53: Overheard; folklore? Lattice-based NIKE: param R, pubkeys aR+2e, Rb+2f share secret aRb mod 2; use large enough q/noise to avoid wraparound.
2017.01.16 19:53:40, replying to "JP Aumasson (@veorq)": RFC 7748: "important that the arithmetic used not leak information about the integers". The paper is wrong when it claims compliance. @veorq
2017.01.06 15:11:30: There is a parallel universe where NIST's quantum random numbers have all been 0 and papers are asking "Why doesn't quantum physics work?"
2017.01.05 22:03:33: Giving away some United beverage vouchers at #realworldcrypto. Valid on United flights until end of this month, not valid for premium wines.
2016.12.28 17:25:39: Flew @lufthansa on the 23rd. Luggage arrived 28th (AMS-FRA-MUC-FRA-PEK-TPE: yes, 2x FRA) with new LH "RUSH" sticker. What does "RUSH" mean?
2016.12.24 13:17:00, replying to "Thomas Pornin (@BearSSLnews)": PowerPC CPUs typically have variable-time integer multipliers, as do some current low-end ARM CPUs. Need CPU-specific assembly. @BearSSLnews
2016.12.17 12:32:38: New Hope authors announce improved version. Ciphertexts now 2176 bytes instead of 2048 but big code simplifications. https://cryptojedi.org/#newhopesimple
2016.12.10 21:24:13: Is @TUeindhoven really refusing to follow through on a contractually guaranteed salary increase? Stunned. Looking for a good Dutch lawyer.
2016.12.02 13:19:45, replying to "Katzenfreund (@faule_sofakatze)": We didn't submit this year---sadly can't make it. Are there crypto talks you'd like to hear in the future? @faule_sofakatze @hyperelliptic
2016.11.27 01:49:45, replying to "Reini Urban (@Reini_Urban)": Now @Reini_Urban implements the very slow attack from top of page 16 of SipHash paper, while failing to accomplish anything like Appendix B.
2016.11.18 22:34:09: Could this be the first crypto/security talk ever where Alice and Bob are being attacked by Donald rather than Eve? https://cr.yp.to/talks.html#2016.11.15
2016.11.08 15:04:33: A bold claim without evidence from @Reini_Urban in https://github.com/rurban/smhasher/: generic SMT solvers can find keys for SipHash and (seeded) SHA1.
2016.10.31 00:09:49: New blog post "Some challenges in post-quantum standardization" (comments to NIST): https://blog.cr.yp.to/20161030-pqnist.html #standardization #nist #pqcrypto
2016.10.25 22:20:54: Unscientific studies strongly suggest that the most common lie told by Americans is "I have read and agree to these terms and conditions."
2016.10.15 18:13:50: "Democracy" (noun, American slang): A multiple-week mob trial of two accused criminals to decide which one will be the next 4-year warlord.
2016.10.15 19:32:00: True democracy would let me vote directly against dropping bombs, building walls, recording all communication. American "democracy" doesn't.
2016.10.14 21:52:18: Idea for monetizing DNS queries: Scan for NXDOMAIN; check plausibility; quickly register the domain name. Is this patentable? Any prior art?
2016.10.12 20:08:48, replying to "isis agora lovecruft (they/them) (@isislovecruft)": For the record: I'm unable to figure out any connection between reality and this @isislovecruft tweet. She's severely misinformed or lying.
2016.09.22 23:51:05, replying to "Scott Arciszewski (@CiPHPerCoder)": Lots of stuff: hash functions, ciphers, ECC, post-quantum systems. Looking forward to in-depth discussion of what to optimize. @CiPHPerCoder
2016.09.22 23:36:03: Workshop coming up next month on measuring and improving crypto performance: http://ccccspeed.win.tue.nl/ Registration only 130 EUR until 27 Sep.
2016.09.21 17:17:21: New fast _non-quantum_ algo from Bauch, @hashbreaker, @hdevalence, @hyperelliptic, @cvvrede for some number fields: Find short g given <g>.
2016.09.03 12:35:04, replying to "hanno💉💉💉💉 (@hanno)": Lattices: inadequate security analysis, illustrated by recent breaks of _some_ systems. "Doesn't think it's secure" is overstatement. @hanno
2016.09.01 00:14:13: "Free speech is at risk at the very institution where it should be assured: the university! Please pay now to read the rest of this essay."
2016.09.01 00:25:26: Btw, can anyone explain to me why the UChicago president wrote "assure" rather than "ensure"? Should he come up to UIC for English classes?
2016.08.20 20:43:50, replying to "Stefano Tessaro (@StefanoMTessaro)": Generic answer: try to establish consensus on the applied-cryptographers-at-crypto@googlegroups.com mailing list. @StefanoMTessaro @kennyog
2016.08.17 07:52:03, replying to "Stefano Tessaro (@StefanoMTessaro)": Pure proof talks have never been acceptable content for AppliedCrypto. Were you proposing any new cryptosystems? @StefanoMTessaro @kennyog
2016.08.16 19:29:58, replying to "kennyog (@kennyog)": AppliedCrypto has always rejected FHE papers. I find "overstretched NTRU" quite interesting but I can't honestly say it's applied. @kennyog
2016.08.15 21:54:22: Flipping between the CHES and Crypto schedules? Try the merged (and more detailed) AppliedCrypto 2016 schedule: https://2016.applied.cr.yp.to/schedule.html
2016.07.27 12:24:41, replying to "Jacob Alperin-Sheriff 🐵 (@DemocraticLuntz)": 2945 followup papers so far. Many citations come after, and fail to mention, poly-time quantum key recovery.
2016.07.26 13:14:40: Lattice salesmen continue to (1) claim PQ and (2) point to Gentry's STOC 2009 FHE paper, not mentioning the poly-time PQ break of the paper.
2016.07.26 13:20:09: Lattice salesmen proudly advertise GGH multilinear maps and IO, but then say "Bad systems! No theorems!" when the security claims crumble.
2016.07.26 13:32:10: Lattice salesmen claim "hardness guarantees" for LWE/Ring-LWE while "forgetting" to emphasize critical limitations, such as HUGE key sizes.
2016.07.26 13:35:00: When users fall prey to this bait and switch, mixing up practical Ring-LWE with HUGE Ring-LWE, lattice salesmen deny responsibility.
2016.07.26 13:42:45: Lattice salesmen pretend that attacks are well understood, and respond to research with denial. Why am I reminded of quantum cryptographers?
2016.07.09 21:04:43, replying to "Trevor Perrin (@trevp__)": Happy to hear that the key isn't attached to the ciphertext. The paper still sounds wrong to me; should clarify. @trevp__ @sweis @alexstamos
2016.07.09 12:25:37, replying to "Steve Weis (@sweis)": If it's ciphertext then how can it be reported? Sounds like they want a commitment to the plaintext M: e.g. SHA-256(R,M). @sweis @alexstamos
2016.07.08 22:29:31, replying to "Alex Stamos (@alexstamos)": So you're revealing a MAC of each plaintext under a key that's also revealed? Are plaintexts guaranteed to have high entropy? @alexstamos
2016.07.06 22:47:44: Dear @ischpc: Do you sell lists of email addresses of ISC conference participants? Or do you think spammers have broken into your network?
2016.07.07 02:52:25: Three high-entropy email addresses used solely for ISC'12, ISC'13, ISC'14 conference registrations received >100 spam messages since March.
2016.07.02 12:56:01: unison-2.48, unison-2.40, etc. are well known to be incompatible protocols. Ubuntu now packages just _one_ of these. Interoperability fails.
2016.07.01 18:30:04, replying to "Tobias (@krono)": Wikipedia defines German-American as any American with a German ancestor. Stupid definition, as illustrated by your misunderstanding. @krono
2016.07.01 00:36:32: Wikipedia's notion of "German-American" (as in https://en.wikipedia.org/wiki/Daniel_J._Bernstein) is idiotic. Is Trump "German-American"? Is Clinton "Dutch-American"?
2016.06.24 23:02:48: Non-computer version of https://www.eff.org/files/2016/06/23/matish_suppression_edva.pdf: "Burglaries are feasible, so the government doesn't need a warrant to search your home."
2016.06.18 01:42:05, replying to "Robᵉʳᵗ Graham💰 @erratarob@infosec.exchange (@ErrataRob)": Freedman v. Maryland was entirely about enforcing due process for censorship, and was the foundation of my court case.
2016.06.18 01:32:16, replying to "Robᵉʳᵗ Graham💰 @erratarob@infosec.exchange (@ErrataRob)": First part of your tweet is totally idiotic; please issue an erratum. Random examples: https://cr.yp.to/djbdns/namedroppers/20000204012814-28947-qmail@cr-yp-to; Bernstein v. U.S.
2016.06.18 02:03:29: Let me rephrase. The first part of your tweet is objectively false. You stated it in reckless disregard of well-documented facts.
2016.06.08 13:20:38, replying to "Quinn Norton (@quinnnorton)": 1. What was done to you sounds truly horrifying on many levels. 2. What precisely _in my blog post_ are you disagreeing with? @quinnnorton
2016.06.07 03:17:20: New blog post "The death of due process": https://blog.cr.yp.to/20160607-dueprocess.html #ethics #crime #punishment
2016.05.27 00:46:44, replying to "JP Aumasson (@veorq)": No, conference-reviewing errors are a totally different issue from eprint falsely pretending to be open.
2016.05.27 00:33:57, replying to "Anna Lysyanskaya (@AnnaLysyanskaya)": We've collected a pile of actual quotes from the eprint censors, totally out of whack with posted rules. @AnnaLysyanskaya @nikitab @benadida
2016.05.26 17:16:35, replying to "Ben Adida (@benadida)": This wasn't my paper; it's just one of many inexcusable eprint censorship incidents that I've heard about.
2016.05.26 17:13:01, replying to "Anna Lysyanskaya (@AnnaLysyanskaya)": Quote from censors re extra review time: "paper makes direct claims about errors in a published paper". Welcome to reality. @AnnaLysyanskaya
2016.05.23 22:35:02, replying to "Samuel Neves (@sevenps)": Each direction of diffusion of the differential is blocked by a 1. So try 2 rounds |, 2 rounds &.
2016.05.23 09:21:50, replying to "Paul Crowley (@ciphergoth)": Yes, ^ at the end. Same rotation constants should be good; offhand I'd expect 7 8 12 16 to be worse. Thinking about 1 8 11 16. @ciphergoth
2016.05.22 22:38:40: Must... do... constructive... tweet... Ok, I'm hereby requesting cryptanalysis of Sorsa20. Salsa20, change + to |; much better for hardware.
2016.05.22 22:33:25: Marketing: 3400 "leaders" endorsed QManifesto. https://ec.europa.eu/digital-single-market/en/news/european-strategy-quantum-technology-endorsed-3400-key-players Reality: most signers don't even lead their own groups! Students etc.
2016.05.22 22:21:15: New mailing list for security experts tracking dishonest security claims (not just #quantummanifesto): snakeoil+subscribe@googlegroups.com
2016.05.18 14:35:33, replying to "Moxie Marlinspike (@moxie)": The agility @moxie describes in https://whispersystems.org/blog/the-ecosystem-is-moving/ does not need centralized messaging. A single auto-updated software source suffices.
2016.05.17 00:16:36: New blog post "Security fraud in Europe's 'Quantum Manifesto' ": https://blog.cr.yp.to/20160516-quantum.html #qkd #quantumcrypto #quantummanifesto #QuantumEU
2016.05.13 13:38:23, replying to "Alec Muffett (@AlecMuffett)": In other words, blocking Tor users from seeing your site is more than 98% ineffective as a security strategy. @AlecMuffett @matthew_d_green
2016.05.12 04:51:49: New paper "NTRU Prime" w/Chuengsatiansup, @hyperelliptic, @cvvrede: https://ntruprime.cr.yp.to/ntruprime-20160511.pdf Trying to make lattice-based crypto less scary.
2016.05.07 02:57:02, replying to "((( danny stormiels ))) 🗽 (@LookAtMeImDanny)": I didn't ask you for an unfocused brain dump. I asked a specific question; you dodged it. You've also piled up many errors.
2016.05.06 23:21:37, replying to "((( danny stormiels ))) 🗽 (@LookAtMeImDanny)": OK, @LookAtMeImDanny, I'm curious. You admit that BB84 is not "actually secure"; what do you say is the error in GLLP's BB84 security proof?
2016.05.05 02:09:34, replying to "You and 52 others (@bahstgwamt)": "Busy-loop to const time T" is an auditor's nightmare: you'll underestimate T _and_ screw up the loop _and_ miss most time channels. @kragen
2016.05.01 16:43:22, replying to "((( danny stormiels ))) 🗽 (@LookAtMeImDanny)": Actually, the paper explicitly covers entanglement-based QKD too: e.g. [17]. Try reading+understanding _before_ responding. @LookAtMeImDanny
2016.05.01 15:21:14: Have you withdrawn your false claim that quantum crypto keeps data "secret by the properties of quantum mechanics"? https://twitter.com/preskill/status/717771622606712833
2016.05.01 14:33:26: New EU Reptile Manifesto hypes snake oil's medical benefits; asks for 1 billion EUR. #qkd #quantumcrypto #quantuminternet #quantummanifesto
2016.05.01 14:20:54: QKD is worse: fraudulently claims security "guaranteed by the laws of physics." See my paper https://cr.yp.to/papers.html#holographic https://twitter.com/FredericJacobs/status/726678625051795458
2016.04.30 15:31:51: http://qurope.eu/manifesto has insane QKD security claims and no quantum cryptanalysis. Comments can still be added at https://ec.europa.eu/futurium/en/content/quantum-manifesto-quantum-technologies-0.
2016.04.30 22:44:34: Posted my own comment now on this draft "Quantum Manifesto": https://ec.europa.eu/futurium/en/comment/6479#comment-6479 They should include post-quantum crypto, scrap the QKD.
2016.04.19 09:25:15: Criminals join NYPD in calling for anti-crypto legislation and returning us to a golden age of crime. https://www.bostonglobe.com/business/2014/09/07/how-tech-making-car-theft-obsolete/4qzCXHQHiQPvcjqewQWIZJ/story.html #UnlockJustice
2016.04.13 00:47:15: Goldwasser and Kalai claimed X1. I gave easy counterexample to X1. Apparently they then switched to X2. But X2 is just as easy to disprove!
2016.04.13 00:49:50: Clearly Goldwasser and Kalai have also managed to confuse Chatterjee, Koblitz, Menezes, and Sarkar. C'mon, people, this is not a hard issue.
2016.04.13 00:54:41: Take, e.g., discrete logs in the multiplicative group of \Z/m where m+1=2^2^k. This problem has full worst-case-to-average-case reductions.
2016.04.12 15:45:02: Most recent public breaks of NSA's Simon+Speck have jumped to ~70% rounds for all variants. NSA tries to pretend it knew this would happen.
2016.04.12 15:49:48: A minute later the same NSA designer advocates 48-bit block size and claims incorrectly that CTR mode makes this safe for gigabytes of data.
2016.04.12 16:04:47: NSA claims that having 70% of Simon+Speck broken is ok. Why? "AES." Um, how about ARX? "ChaCha." But ChaCha has much bigger security margin.
2016.04.01 21:39:50: After hearing about the use of nail-polish remover by terrorists, I've decided to quit my long career in the nail-polish industry. Ban NPR!
2016.03.28 14:33:58, replying to "(@AWPeet2)": Seeing it as a side channel might be a new perspective but generalizes EM SCA in the same way the principle itself generalizes EM.
2016.03.28 04:08:12: In 2013, Sahai labeled his new obfuscation work as an "iron wall" and dismissed previous work as mere "speed bumps": http://newsroom.ucla.edu/releases/ucla-computer-scientists-develop-247527
2016.03.28 04:12:56: Now Sahai says the "iron wall" is broken in poly time: https://eprint.iacr.org/2016/147 In many ways the older work seems considerably more advanced.
2016.03.28 04:17:32: Of course, mistakes do happen, but the advertising by Sahai et al. was never scientifically justified. Did they ever read the previous work?
2016.03.28 03:56:12: Audio now available (and slides were already available) for my talk "The post-quantum Internet" from PQCrypto 2016: https://cr.yp.to/talks.html#2016.02.24
2016.03.28 03:43:28, replying to "Taylor Hornby 🛡❤️ (@DefuseSec)": Do you see cryptographers claiming that one-time pads provide absolute security _guaranteed by the fundamental laws of physics_? @DefuseSec
2016.03.27 17:56:53, replying to "JP Aumasson (@veorq)": Rudolph already suggested throwing QKD into a black hole, but my paper expresses skepticism that this will truly stop communication. @veorq
2016.03.27 07:26:53: Posted new paper "Is the security of quantum cryptography guaranteed by the laws of physics?" https://sidechannels.cr.yp.to/qkd/holographic-20160326.pdf #holographicprinciple
2016.03.15 20:59:28: New post "Thomas Jefferson and Apple versus the FBI" https://blog.cr.yp.to/20160315-jefferson.html: An introduction to freedom of speech for software publishers.
2016.03.14 10:47:02: Fun game to play: Take statements from Comey et al. Replace "smartphones" with "brains"/"memories"/"thoughts". Technology will get us there!
2016.03.14 15:49:17: "Everybody is walking around with a Swiss bank account in his brain if government can't get in. You cannot take an absolutist view on this."
2016.03.14 15:52:40: "How do we solve or disrupt a terrorist plot if law enforcement can't access the memories and thoughts inside suspected terrorists' brains?"
2016.03.14 09:49:59: "First 10 years of Curve25519" audio now online: https://cr.yp.to/talks/2016.03.09/audio.ogg Presentation: https://cr.yp.to/talks/2016.03.09/slides-djb-20160309-4x3.pdf A4: https://cr.yp.to/talks/2016.03.09/slides-djb-20160309-a4.pdf
2016.03.10 19:24:56: "You thought your communication was secure? Quantum computers are coming!" http://www.scienceandcocktails.org/2016/Communication.html (Copenhagen w/@hyperelliptic next month)
2016.02.29 08:27:31: Unanimous Supreme Court defended privacy of NAACP membership lists in 1958: http://caselaw.findlaw.com/us-supreme-court/357/449.html Today it's hard to imagine such freedom.
2016.02.27 08:52:36: Checking PKC 2006 records... @SteveBellovin: "For most users, eavesdropping isn't a major threat. It happens, but it's hard to do at scale."
2016.02.27 09:05:40: In Taipei getting talk ready for PKC 2016. Was asked to focus on practical public-key crypto, but audience is mostly theoreticians. Tricky.
2016.02.24 23:07:16: Urgent: Protect today's civil-rights workers against an attacker who records their ciphertexts and eventually builds a big quantum computer.
2016.02.24 23:09:31: Not urgent: Protect a civil-rights worker's laptop against Gandalf magically transforming the laptop into quantum computer with quantum I/O.
2016.02.22 05:48:39: I see 125 people in the room for the PQCrypto school here in Fukuoka. Rumors of more than 200 people registered for the PQCrypto conference.
2016.02.24 06:34:45: 238 attendees for PQCrypto 2016! Videos are streaming to two adjacent rooms. PQCrypto now plans to accelerate from ~18 months to ~12 months.
2016.02.22 02:59:48: Wow: ssh upgrade breaks my logins to 100 machines. Fortunately client-side. Instant workaround w/@QubesOS: swap VM from @fedora to @debian.
2016.02.18 22:32:28: I wonder what the reaction would be to headlines saying "FBI orders Apple engineers to build tools to help FBI spy on civil-rights leaders."
2016.02.11 14:46:52: Biking through Utrecht. Box near the road is labeled "Dijkstra Transport." Immediate reaction: "I guess they always take the shortest path!"
2016.02.07 03:21:06: Pornin re SafeCurves: TLS uses ECC "in a rather simple and direct way where such risks don't apply." 8 months later: http://web-in-security.blogspot.com/2015/09/practical-invalid-curve-attacks.html
2016.02.03 00:12:21: Christian Grothoff asks: If we use a 1TB post-quantum RSA key in TLS, will we cause a buffer overflow in Bluffdale's RSA-key storage units?
2016.02.02 22:15:46: Still time left to finish papers for 15 Feb submission deadline to ArcticCrypt. Midnight sun! Polar bears! Untrained tourists with shotguns!
2016.02.02 20:26:41: AES-128 weakness: see, e.g., https://blog.cr.yp.to/20151120-batchattacks.html. Chrome doesn't support AES-256-GCM (https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=47&platform=OS%20X) but maybe gets CBC right.
2016.02.02 11:43:45: My SSL_CTX_set_cipher_list goals: minimize options; try to avoid dangers (such as AES-128); but don't break the connection, unless it's XP.
2016.01.30 16:13:02, replying to "Snow B. Petrel (@sbp)": .@sbp It's something new+experimental: "simplerssl". Two OpenSSL cesspool tanks, like Titus, but factors stunnel-type API via sslwrap-type.
2016.01.30 19:28:17: I run publicfile's "httpd /public/file" under both "tcpserver 0 80" and "tcpserver 0 443 simplerssl /root/simplerssl"; no forwarding needed.
2016.01.29 19:24:58: Exercise in visual display of quantitative information: What is this graph doing wrong, and how should it be fixed? https://www.qubes-os.org/counter/
2016.09.03 20:58:14: The https://www.qubes-os.org/counter/ graph is much more readable now. Apparently Qubes has leaped from 6000 to 16000 IP addresses in the past year.
2016.01.29 12:20:33: gitolite: your repos are on your ssh servers; easier than github for new repos + chmod; you don't have to promise to pay github's lawyers.
2016.01.27 20:20:11: NSA FAQ: Why allow RSA-3072? Short-term cost. Why bar 256+force 384? Long-term sec. Is 384 long-term secure? No. Is NSA confused? Massively.
2016.01.27 21:45:37: Coming soon: NSA Guide To Protection Against Winter. "Problem: Cold air is attacking my throat. Soln: Thicker pants. Or skip the underwear."
2016.01.26 14:49:56: Still not decapitating the RC4 zombie but looks like a solid shot to the body: http://eprint.iacr.org/2016/063 Is RC4 still the smart-grid standard?
2016.01.26 13:50:14: "The aim of the policy in the future is that ... 35% of the doctoral candidates in the TU/e will be women." WTF? https://static.tue.nl/uploads/media/Personnel_Policy_for_the_Academic_Staff.pdf
2016.01.26 21:27:25: Amused by the split of responses between "Wow, 35% would be a real achievement!" and "How could these nitwits state a FUTURE AIM below 50%?"
2016.01.25 04:04:51: Reviewing despicable examples of #eprintiacrorgcensorship. Starting to see a pattern: is it all about marketing IACR to funding agencies?
2016.01.27 10:32:18: Case study: An eprint submission was delayed two weeks, explicitly subjected to review because it pointed out errors in a Eurocrypt paper.
2016.01.21 21:08:26, replying to "David Leon Gil (@coruus)": @coruus Was this http://arxiv.org/abs/1506.07269? What was the eprint editors' excuse for rejecting it? #eprintiacrorgcensorship
2016.01.19 01:44:46: Nice MLK article in Slate: http://www.slate.com/articles/technology/future_tense/2016/01/what_the_fbi_s_surveillance_of_martin_luther_king_says_about_modern_spying.html Is suppressing dissent the largest purpose and largest effect of government surveillance?
2016.01.18 16:52:22: Salesman offering your company "unbreakable Quantum Key Distribution"? Show him http://arxiv.org/pdf/1601.00993v1.pdf, and post his response for scrutiny.
2016.01.18 17:01:48: If QKD security is "guaranteed by the laws of quantum physics" (http://swissquantum.idquantique.com/?-Quantum-Cryptography-) then Vadim Makarov transcends the laws of physics!
2016.01.18 17:20:35: Part of what's going on here is bait-and-switch. "QKD" can mean (1) a "provably secure" fantasy; (2) the snake oil being sold commercially.
2016.01.18 17:22:45: But there's an even more fundamental problem: the independence hypotheses in the "security proof" are inconsistent with the laws of physics.
2016.01.18 17:55:20: Pure fantasy QKD assumes that some Alice+Bob actions are independent of Eve. But that's simply false. Can't avoid radio waves, gravity, etc.
2016.01.18 23:15:38: Holographic principle says, roughly, that secrets are stolen at cost cd^n by an attacker at distance d. The (c,n) for QKD seem horribly low.
2016.01.18 23:24:04: Typical QKD marketing claim: All secret keys are guessable "eventually". Consensus of actual physicists: All physical computations are O(1).
2016.01.10 23:01:46: Amazing: The editors of IACR's "essentially unrefereed" archive https://eprint.iacr.org refuse to add our new https://cr.yp.to/newelliptic/nistecc-20160106.pdf paper.
2016.01.12 22:45:23: Okay, now working on a complaint to the IACR Board of Directors regarding #eprintiacrorgcensorship. I know some stories; happy to hear more.
2016.01.10 13:53:12, replying to "Nicolai (@bitbbq)": @bitbbq Temporary issue; letsencrypt beta is rate-limited. Could do multi-SAN but clear advantages to separating certs for different names.
2016.01.10 13:44:26, replying to "Tanja Lange (@hyperelliptic)": Maybe this could be added somehow to Qualys SSL Server Test? "This company uses Dual EC. Grade capped to F." @hyperelliptic @stevecheckoway
2016.01.07 21:53:37, replying to "Tancrède Lepoint (@Leptan)": You're saying that the documented history of lottery security failures comes from lotteries that weren't _designed_ to be secure? @Leptan
2016.01.07 16:49:18, replying to "Will Glynn (@delta407)": @delta407 No. The routing semantics need to be tweaked (see https://cr.yp.to/djbdns/ipv6mess.html), and then need to be made mandatory for IPv6 software.
2016.01.07 08:44:24: Earlier this week: awesome High Assurance Crypto Software workshop organized by @trevp__. Expect a tiny guaranteed-zero-bugs crypto library.
2016.01.07 08:19:28, replying to "martin ➬ no longer on shitter (@martinkrafft)": Try telling your manager that you're going to make your web server IPv6-only, cutting off 90% of Internet users. Ridiculous. @martinkrafft
2016.01.07 07:54:45: Deep confusion in https://blog.sesse.net/blog/tech/2016-01-06-20-54_ipv6_non_alternatives_djbs_article_13_years_later.html doesn't manage to hide the core issue: "The _single_ benefit is that they won't have to renumber."
2016.01.07 08:00:09: Easy IPv6 software+spec changes today, adding the critical IPv4-addresses-work-without-renumbering feature, would still have huge benefits.
2016.01.07 02:10:08: New paper "Failures in NIST's ECC standards" w/@hyperelliptic, in response to NIST reopening FIPS 186-4 for comment: https://cr.yp.to/newelliptic/nistecc-20160106.pdf
2016.01.03 15:18:54: I use Tor Browser for all my regular web surfing. The occasional sites that don't like it (e.g., nytimes) turn out to be totally skippable.
2016.01.01 19:55:20, replying to "Whitney Merrill (@wbm312)": @wbm312 I understand time was limited. Why not say "The govt says it can search anything at the border, but courts have set some limits"?
2016.01.01 19:40:32, replying to "Whitney Merrill (@wbm312)": @wbm312 You said "There is no fourth amendment protection at the U.S. border." But that's not true. There has always been _some_ protection.
2016.01.01 19:10:45, replying to "Whitney Merrill (@wbm312)": @wbm312 Even before recent cases (House, Cotterman, Kim, and the obvious impact of Riley) "4th doesn't apply at border" was an exaggeration.
2016.01.01 18:54:55: Say you're an agency exploiting 0-days. What news makes you happier? (1) "Full" disclosure+panic. (2) "Responsible" disclosure+complacency.
2016.01.01 18:39:16: Enjoyed reading https://www.eff.org/files/2015/09/10/saboonchi_eff_amicus_brief.pdf but why has @EFF not corrected https://www.eff.org/files/filenode/eff-border-search_0.pdf? Heard same mistake in @wbm312 talk at #32c3.
2015.12.31 23:58:54: alpha release of gfverif (from @cryptojedi and me), plausible path towards guaranteed bug-free state-of-the-art ECC: http://gfverif.cryptojedi.org
2015.12.26 01:29:31, replying to "Andrew Ayer (@__agwa)": The attacker can use RSA_NO_PADDING to find decryptions of small primes; post-access can decrypt anything that happens to be smooth. @__agwa
2015.12.26 01:36:36: Even if you limit to PKCS, has anyone analyzed how much is leaked from long fake "hashes"? Hashing should be inside security module. @__agwa
2015.12.25 05:49:01: Suppose an OpenSSL buffer overflow allows code exec. Target is running Titus. Can't attacker steal key using, e.g., RSA_NO_PADDING? @__agwa
2015.12.24 09:25:59: Hey, RIM/Blackberry/Certicom: Juniper is violating your Dual EC escrow-avoidance patents. https://kb.juniper.net/InfoCenter/index?page=content&id=KB28205&pmv=print&actp=LIST https://projectbullrun.org/dual-ec/patent.html
2015.12.24 09:10:05: Xmas movies! https://psc2015videos.projectbullrun.org w/@rootkovska @kennyog Zimmermann @JonSolworth @csoghoian @claudsdayz Goldberg Grothoff @ioerror @n8fr8
2015.12.21 04:31:21: Anonymous reviewer of http://cr.yp.to/papers.html#multischnorr: "Mistakes do happen in cryptography." This sloppy attitude is exactly what attackers want.
2015.12.19 03:33:55: NSF loudly proclaims that proposals are confidential. Collects huge database of ideas. Leeches have started learning to mine this database.
2015.12.19 03:37:54: We all know that short "abstracts" of funded grants are put online. But the full proposals have many ideas and details beyond the abstracts.
2015.12.19 03:39:39: Instead of letting awardees decide when an idea is scientifically ready to publish, NSF gives away the full proposals to anyone who asks.
2015.12.19 03:42:22: This is buried on page 62 of an NSF document that nobody reads. If it were widely known then proposals would be written quite differently.
2015.12.06 00:42:40: Curve25519 is conservative prime-field ECDH. Faster _non-conservative_ DH isn't news: first software online in 2006! http://cr.yp.to/talks.html#2006.09.20
2015.12.06 00:51:36: Best option known for non-conservative ECDH is Kummer: https://eprint.iacr.org/2014/134 https://eprint.iacr.org/2014/379 FourQ is similar speed but patented.
2015.12.05 18:32:04: Context: Krebbers+Wiedijk pointed out insane vagueness in ANSI C memory model. ANSI C authors (compiler writers) were indisputably sloppy.
2015.12.05 17:14:03: ANSI C committee member at workshop: roughly "We know it sucks. We're volunteers. We don't have time to fix it." HEY WAIT THAT'S OUR BIBLE!
2015.12.03 16:40:17: NIST has reopened its ECC standards (really from NSA) for comment. One day left until the deadline (Fri 4 December): https://federalregister.gov/a/2015-26539
2015.11.30 23:24:48: Support the police state! It doesn't stop terrorists, but it does stop those scary anti-corporate climate activists: http://www.theguardian.com/environment/2015/nov/27/paris-climate-activists-put-under-house-arrest-using-emergency-laws
2015.11.30 18:23:42: Patent 6202150 claims generating keys with "a proof that the keys were generated by a specific algorithm". Nobody does that. Bogus lawsuit.
2015.11.26 01:13:57: U.S. says: Didn't know it was a hospital. GPS+radio were broken. Attacked anyway. http://edition.cnn.com/2015/11/25/politics/afghanistan-kunduz-doctors-without-borders-hospital/index.html Prior art: https://en.wikipedia.org/wiki/Dr._Strangelove
2015.11.24 17:46:14: Post-Snowden Crypto registration page back up for the moment after moderate DoS: https://hyperelliptic.org/PSC/ Maybe should do regs via Twitter?
2015.11.23 14:46:49: Real world: Users hate failures like https://kb.isc.org/article/AA-01167. C lawyer's fantasy world: Users care whether gcc vectorizes variable shifts.
2015.11.23 10:20:25, replying to "Dan Kaminsky (@dakami)": @dakami That's a big part of it. Forcing compilers to _define_ behavior turns this into something documented, an explicit quality statement.
2015.11.23 10:17:09: Crypto analogy: Huge failure, http://web-in-security.blogspot.com/2015/09/practical-invalid-curve-attacks.html. Do we blame the programmers? http://cr.yp.to/talks/2015.06.11/slides-djb-20150611-a4.pdf instead says: Fix the standards!
2015.11.23 09:58:10, replying to "John Regehr (@johnregehr)": @johnregehr The prior literature has failed to solve the problem. We need new compiler maintainers who prioritize "Don't break the system."
2015.11.23 09:43:51: C lawyers now acting stupid, feigning ignorance of what C programmers want. We want the compiler to _define_ behavior and _stop fucking up_.
2015.11.23 09:45:24: There's tons of "undefined behavior" in the C "standard" that should have said "implementation-defined". This is not a hard thing to grasp.
2015.11.22 23:28:13, replying to "Aris Adamantiadis ☠ (@aris_ada)": @aris_ada This isn't about me. The last time I saw gcc breaking my code was an outright gcc bug many years ago (strcmp vs memcmp for x?s:t).
2015.11.22 23:31:27: @aris_ada But the bigger picture is gcc "upgrades" producing system failures, security problems, unreadable workarounds. Huge waste of time.
2015.11.22 23:35:39: @aris_ada The C lawyers try to blame the victims, but the C "standard" is a compiler writer's delusion, violated by _most_ deployed C code.
2015.11.22 21:30:46: C lawyer: "My client, a gcc developer, started shooting speeding drivers only yesterday, but this doesn't mean speeding has ever been safe!"
2015.11.22 21:35:47: Old gcc upgrade: Bug fixes, some speed, some intrinsics. New gcc upgrade: I AM THE LORD THY GCC AND I WILL BREAK YOUR SYSTEM. FEAR MY WRATH.
2015.11.22 22:00:24: Lawyer for gcc developer doesn't understand when to quit: "By shooting drivers who speed, my client is helping society learn not to speed!"
2015.11.22 23:07:17: C laywers: "We wrote a STANDARD saying it's okay for us to shoot drivers who speed!" Is it really so hard to understand that you screwed up?
2015.11.21 16:01:27, replying to "catid (parody) (@MrCatid)": @oculuscat @zooko The paper reports >0.4 Haswell cycles/byte for PCG; ChaCha20 is 1.2; ChaCha8 is 0.6. Has anyone evaluated PCG's strength?
2015.11.21 15:42:00: California freeway, everyone doing 75mph. Suddenly gcc developer pulls out shotgun, starts shooting drivers. "FOLLOW THE RULES!" he screams.
2015.11.21 15:44:10: Me: "Lock him up." C lawyer #1: "You're biased. This tape shows you SPEEDING!" C lawyer #2: "Hmmm, does it?" Pointless discussion ensues.
2015.11.21 15:49:12: Fortunately, in the real world, the systems that we all rely on are built by engineers prioritizing users, not by crackpot lawyers... right?
2015.11.21 00:21:46: The C "standard" is an unstable series of sloppy documents that have never accurately documented the needs of typical real-world C code.
2015.11.21 00:36:11: It's crazy that a huge community of C programmers has to clean up the _correctness_ mess whenever gcc or llvm adds a sloppy _speed_ tweak.
2015.11.21 00:39:55: What we actually need is a free compiler that says "We understand that the standard is buggy. We will preserve the obvious meaning of code."
2015.11.20 16:55:15: New blog post "Break a dozen secret keys, get a million more for free": http://blog.cr.yp.to/20151120-batchattacks.html ECRYPT crossposting: http://ecrypt-eu.blogspot.de/2015/11/break-dozen-secret-keys-get-million.html
2015.11.18 21:19:53: Startup idea: "Economy-Class Airlines". Resells (+5% profit) "business-class seats" from UA etc. as govt-reimbursable "economy-class seats".
2015.11.18 01:30:46: Fantastic lineup of speakers for https://hyperelliptic.org/PSC: Appelbaum Diaz Freitas Goldberg Grothoff Paterson Rutkowska Soghoian Solworth ...
2015.11.18 01:37:56: ... and conference hotel (Crowne Plaza Brussels Le Palace) is offering some discounted rooms through at least Wednesday 18 Nov, Europe time.
2015.11.17 12:38:29: I run some HTTPS servers. Protecting against ISPs: good. Privilege escalation via Apache+OpenSSL bugs: bad. Are there any auditable options?
2015.11.17 12:42:10: How hard would it be tweak libtlssep to build something like stunnel with every connection separately jailed? Has anyone already tried this?
2015.11.16 22:00:21: My last dozen calls using Skype's SkypeOut have had amazingly low sound quality. In unrelated news, I hear that Microsoft now sells phones.
2015.11.09 11:01:14: If AMD (and NVIDIA?) can be sued merely for selling stripped-down cores, surely quantum-crypto vendors can be sued for claiming "security".
2015.11.02 18:26:23: Clearly http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html is much more modular and portable than systemd; presumably more robust. Has anyone benchmarked startup time?
2015.11.01 06:12:47: Pages 1-12 of https://eprint.iacr.org/2015/1034.pdf: Here's a CT defense. Page 13: Attacker dodges defense, "opening the doors to further research". Sigh.
2015.11.01 06:17:09: Paper tries to detect CT attacks. Doesn't explain what to do if alarm is tripped. Doesn't cite comprehensive protection: constant-time code.
2015.11.01 06:19:04: How blatantly do crypto researchers have to say "Our goal is to write more research papers; screw the crypto users" before the users notice?
2015.10.28 18:49:58: What I learned from this year's UI ethics training: After forcing Alice to clean his house for free, boss Bob was suspended... for 7 days.
2015.10.23 17:45:28: "NSA wants to look good" explains NSA's new post-quantum announcements, but the details have cryptographers laughing at NSA's incompetence.
2015.10.23 11:50:39: Post-quantum crypto conference series started 2006 w/@hyperelliptic. Next: Japan in Feb 2016. See our PQCrypto site: http://pqcrypto.org
2015.10.14 13:47:41: "Crypto researchers: We understand what game we're in... how we get papers published... Boring crypto is a threat." http://cr.yp.to/talks/2015.10.05/audio.ogg
2015.10.13 02:16:48: Drone strike takes out a teenage security proof. Non-American victim so it's clearly ethical. Is 13 years a record? http://ed25519.cr.yp.to/multischnorr-20151012.pdf
2015.09.27 17:52:11: "Verifiably pseudo-random" Brainpool curves weren't actually generated by the standard Brainpool procedure. Amazing. http://bada55.cr.yp.to/brainpool.html
2015.09.20 13:10:56: Didn't expect Goldwasser to promote nonsense idea that lattices beat DLPs in worst-case-to-average-case reductions: https://eprint.iacr.org/2015/907
2015.09.08 20:32:26, replying to "Robert Love (@rlove)": @rlove Cool, thanks. (Didn't know index.shtml is archived separately.) "Recognizes there will be a move" isn't "will initiate a transition"!
2015.09.08 18:05:24: Apparently there were two public versions of NSA's Suite B announcement: one dated 11 Aug, one dated 19 Aug. Did anyone save the older one?
2015.08.19 17:07:46: Self-contained SHA3-256/SHAKE/etc. in C: https://twitter.com/TweetFIPS202 Hundreds of cryptographers compete for five years to write nine tweets? :-)
2015.08.13 02:18:46, replying to "CA Services (@DLogBot)": @DLogBot m 5a2790dac75a8f9456da6f57ff117b1078f3a1472810a7bfdecb61ea8e43ce8fa16bb019acf670ae98ed1cf9064b5a3f96fa5348ea5af7b949e10bf56b18f39f
2015.08.12 23:44:56: Wasting my time this week: braindead OS installers requiring 2 drives for RAID 1. Reported years ago by Bruno Wolff: https://bugzilla.redhat.com/show_bug.cgi?id=188314
2015.08.09 23:26:27, replying to "hanno💉💉💉💉 (@hanno)": No. The buggy code never passed NaCl's pre-release auditing procedures. We've been working on automated verification to help audits. @hanno
2015.07.30 12:01:01: It's interesting how leeches such as Elsevier and Springer manage to keep sucking money out of science without contributing anything to it.
2015.07.29 17:03:41: University association pays Springer millions for open access. I ask questions. Springer threatens student with non-publication of a paper.
2015.07.26 23:22:08: Tor Browser basically just works, so the occasional failures surprise me: e.g., http://theintercept.com. https://firstlook.org/theintercept works fine.
2015.07.22 21:50:13: EdDSA (including Ed25519) among 5 signature proposals presented at #IETF CFRG meeting today. Slides: http://ed25519.cr.yp.to/cfrg/20150722.pdf w/@hyperelliptic
2015.07.21 07:40:33: Python script to help compare CFRG signature proposals: http://ed25519.cr.yp.to/cfrg/signatures.py Posting to list failed silently; blocked? server overloaded?
2015.07.01 09:04:00: Early-registration deadline in a few days for Challenges in Authenticated Encryption workshop this month in Utrecht: http://chae.cr.yp.to/workshop.html
2015.06.26 08:14:14: Chicago's Byline Bank: Using our layers of incompetence to hide our theft of your money. Please, please, please don't check the statements.
2015.06.25 01:17:06: Wasn't too hard to tweak a Tails USB stick for 32-bit UEFI on a Bay Trail device. Should I blog the details, or did someone do this already?
2015.06.19 11:38:08: My take: https://eprint.iacr.org/2015/577 ("Twist insecurity") is wrong on far more levels than can possibly be summarized in a 140-character tweet.
2015.06.14 01:41:48: If NIST is planning to spend more than 5 years choosing new curves then the GLV patents will expire and FourQ becomes an interesting option.
2015.06.14 01:54:54: FourQ looks like nice research, less arith than Kummer. But K vectorizes better and apparently MS is still unable to beat it on Haswell etc.
2015.06.13 20:03:39: Huge disputes at NIST's #ECCWorkshop, including meta-dispute "CFRG thought everything through already" vs. "NIST should rethink everything".
2015.06.13 20:42:30: Microsoft marketing team trying hard to resurrect their bogus claim that 2^512-569 is more "rigid" than Mersenne prime 2^521-1. #ECCWorkshop
2015.06.02 09:58:47: In math, a "1024x768" matrix has 1024 rows, 768 columns. But a "1024x768" screen has 768 rows, 1024 columns. How did humanity get to space?
2015.05.31 19:15:10: My abstract for SPACE: "Crypto is a thriving research area, full of excitement, which is exactly what the cryptographic user doesn't want."
2015.05.26 13:05:12: http://www.nature.com/news/bibliometrics-the-leiden-manifesto-for-research-metrics-1.17351 is a fantastic response to "the pervasive misapplication of indicators to the evaluation of scientific performance".
2015.05.25 05:00:08: Wondering about ECC precomputation? Some references: https://eprint.iacr.org/2012/318 Section 3; https://eprint.iacr.org/2012/458; https://eprint.iacr.org/2014/637.
2015.05.20 19:35:37: TLS agility=>more and more insane complexity=>hellish upgrades=>late upgrades=>objections to extermination=>late extermination=>insecurity.
2015.05.20 19:16:25, replying to "Paul E. Hoffman (@paulehoffman)": If the old protocol version has problems: Deploy a new version, and _schedule the extermination_ of the old version. @paulehoffman @RichSalz
2015.05.20 16:32:25: "Algorithm agility" marketers always refuse to take responsibility for the resulting security holes. Blame the protocol! Blame the software!
2015.05.20 13:30:19: "Cryptographic algorithm agility" is a security problem. What we need is something quite different: cryptographic algorithm extermination.
2015.05.20 13:48:10: What we need is, e.g., to _exterminate the code_ for 512-bit DH to make sure nobody is using it. "Algorithm agility" doesn't try to do this.
2015.05.17 00:39:44: An armed university is a polite university: "Units should trade in firearms they no longer need for other firearms." https://www.obfs.uillinois.edu/bfpp/section-12-property-accounting/dispose-of-firearms
2015.05.16 19:32:26: Dear Aram: Thanks for your question about ECC. Bad news: ECC is vulnerable to quantum computers using a Shor variant. http://www.nbc.com/the-blacklist/blog/arams-notes/aramsnotes002txt
2015.05.16 16:19:51: Prediction: SupCt will protect laptops at US border. http://www.kmbllaw.com/does-riley-v-california-affect-united-states-v-cotterman-even-more/ EFF's "border guide" fatalism ignores Riley+Cotterman+House+Kim.
2015.05.12 12:44:19: Listening to a "big data"/"data science" talk. Mentally translating "data" to "surveillance": "... everything starts with surveillance ..."
2015.05.12 12:46:02: "... We need to process the surveillance, store the surveillance. The last step is surveillance analytics for our stakeholders. ..."
2015.05.12 13:00:16: "Philips medical devices collect various surveillance... more than 15% of the surveillance is in different languages... machine translation"
2015.05.12 13:02:27: "The surveillance scientists from Philips Research are working together with people from health care... live surveillance-stream collection"
2015.05.10 14:20:47: Really hoping the video worked for this: "I am the man in the middle." http://cr.yp.to/talks/2015.05.08/slides-djb-20150508-a4.pdf http://cr.yp.to/talks.html#2015.05.08 [media]
2015.05.19 01:20:24: Apparently the "man in the middle" video worked. I seem to have an easy time giving evil talks; this fact scares me. https://projectbullrun.org/surveillance/2015/video-2015.html#bernstein
2015.05.06 11:38:44: Every quantum crypto device built is breakable by Makarov's techniques. Is it ethical to claim "security" for these devices? No. #FETquantum
2015.05.06 11:45:16: General-purpose quantum computers will be revolutionary, but exaggerations ("q crypto helps security"; D-Wave) kill credibility. #FETquantum
2015.04.30 10:50:35: Today is Plagiarism Day at Eurocrypt 2015! Crediting a 2007 Ferguson attack to a 2015 paper and ideal-lattice crypto (NTRU) to a 2006 paper.
2015.04.29 11:28:20: From now on, NSA will only be allowed to collect US data matching the following specific selectors: A, E, I, O, U, consonant, digit, symbol.
2015.04.28 16:46:15: I think we need a multilinear-map-security-hole-of-the-month club. Kudos to the cryptanalysts taking the time to wade through this garbage.
2015.04.18 22:53:48: For the record, I love Wikipedia, and if I make a joke about the occasional error then it doesn't mean that I think there's anything better.
2015.04.18 04:16:53: application/pdf should split into pdfpresentation (default view for horizontal documents) and pdfprint. #technologycanconqueruserignorance
2015.04.17 00:30:33: Slides from my tutorial talk "The death of optimizing compilers" today at ETAPS: http://cr.yp.to/talks.html#2015.04.16 Recording should be available soon.
2015.04.18 03:12:58: Audio now available from my tutorial talk "The death of optimizing compilers" yesterday at ETAPS: http://cr.yp.to/talks/2015.04.16/audio.ogg (direct .ogg link)
2015.04.07 21:14:18: Ideal-lattice marketing dept: "We have found the holy grail of crypto: GGH!" [Squished by quantum Godzilla.] "Um, GGH isn't representative!"
2015.04.06 07:39:17: Success in displaying "ELIMINATE THE STATE" next to American flag at official NIST workshop. http://cr.yp.to/talks.html#2015.04.02 [media]
2015.04.06 06:50:28: Audio+slides from my talk at NIST PQ workshop on the issue of whether algorithms work, especially quantum algorithms: http://cr.yp.to/talks.html#2015.04.03
2015.04.03 16:33:21: At NIST PQ workshop, NSA crypto team gives talk "improving" DH: (1) Make it fragile against any reuse of keys. (2) Send Bob your RNG output.
2015.03.30 20:38:58: http://link.springer.com/chapter/10.1007/978-3-662-46447-2_6 looks like a reinvention of the "anti-collision" part of http://eprint.iacr.org/2012/294, plus easy calculations of examples.
2015.03.16 15:08:07: How does such a simple bug in GNU tar (version 1.26) manage to get past the test suite? mkdir x; touch x/y; ln -s y x/z; tar -lhcf x.tar x
2015.03.15 21:36:43: Happy thought of the day: An attacker who merely finds a browser bug can't listen to my microphone except when I've told Qubes to enable it.
2015.03.14 17:05:00: Understand how design flaws produce failures? No. Deny failures: "This is exactly the kind of 'attack' that DNSSEC is designed to prevent!"
2015.03.14 15:17:07: New blog post "The death of optimizing compilers" #etaps #cpuevolution #hotspots #domainspecific #returnofthejedi: http://blog.cr.yp.to/20150314-optimizing.html
2015.03.09 11:45:55: Ongoing presentation on NIST's "Lightweight Crypto Project" from Meltem Sonmez Turan: "Not meant to be weak." That's a welcome change. :-)
2015.03.09 00:01:54: New algorithms "EREA" and "PRO" to quantify security against side-channel attacks: http://sidechannels.cr.yp.to/pro.html with @hyperelliptic and @cvvrede.
2015.03.02 04:06:43: I buy @united ticket. United charges credit card, sends email. Later: United unilaterally cancels, offers me same ticket for higher price.
2015.02.23 22:43:32, replying to "Ruben Niederhagen (@cryptocephaly)": Released paper+software breaking "point obfuscation" challenge: http://obviouscation.cr.yp.to Joint work w/Hülsing, @hyperelliptic, @cryptocephaly.
2015.02.23 22:15:09: Another high-quality headline from CNN: "Opinion: Not all soccer fans are racist." FBI's Comey disagrees: "Everyone's a little bit racist."
2015.02.18 19:35:00: New blog post "Follow-You Printing" http://blog.cr.yp.to/20150218-printing.html: How Equitrac's marketing department misrepresents and interferes with your work.
2015.02.16 22:31:52: Ok, back to crypto: The GCHQ Soliloquy paper has one little idea that could be devastating for Gentry+SV FHE, GGH multilinear maps, IO, etc.
2015.02.16 20:17:54, replying to "Raphaël Jacquot 🧅🔻☢️💉 (@sxpert1)": Here's the story: Print. Wait. Go to printer. Hold up card, wait, click, wait, click, wait, click, wait. _Then_ printer starts up. @sxpert1
2015.02.16 20:07:28, replying to "Raphaël Jacquot 🧅🔻☢️💉 (@sxpert1)": @sxpert1 No, just annoyed at the new printing system at TU Eindhoven. Maybe a few public warnings can help other people avoid the same fate.
2015.02.16 19:05:17: Equitrac Follow-You Printing. So that your organization's employees can spend time waiting for the printer, instead of the other way around.
2015.02.16 19:06:52: Equitrac Follow-You Printing. Encourage your organization's employees to socialize not just in the coffee room but also in the printer room.
2015.02.16 19:11:05: Equitrac Follow-You Printing. Because clicking "Print" is too early to make a commitment: what if there's a better printer for me out there?
2015.02.16 19:28:02: Equitrac Follow-You Printing. If you make the printer REALLY ANNOYING then your employees will print less and your business will save money.
2015.02.15 02:27:08: Marketer, missing the point, says: Don't encourage kids to build cars out of Legos; ask car dealer for more options. http://www.wired.com/2015/02/should-we-really-try-to-teach-everyone-to-code/
2015.02.14 21:00:15: Featured on today's edition of "Simple Crypto Things Quantum Cryptography Can't Do": Use the Internet to broadcast _signed_ OS upgrades.
2015.02.14 02:55:31: We're the government. It's our job to listen to the people, but pesky judges keep getting in the way. Please help us! http://cr.yp.to/talks/2015.02.11/audio.ogg
2015.02.06 00:05:10: Expected: To distract from his incompetence, PHB issues bogus accusations of rudeness. Unexpected: PHB loses temper---yells "IT'S THE TONE!"
2015.01.29 04:10:15: Starting to appreciate the power of Qubes: one window is a movie player packaged in Debian, another window is Sage packaged in Fedora.
2015.01.27 17:12:37: TLSWG->CFRG: Just checking, is 25519 secure? Is there anything better? [12 months pass.] CFRG->TLS: Hold on, we're arguing about endianness.
2015.01.18 16:55:07: Peter Schwabe's "Eliminating timing side-channels: a tutorial" starting in a few minutes (11:00) at #shmoocon; first room from the middle.
2015.01.15 16:06:12: The cryptanalyst comes into view. Her prey, the designer, sees her. His eyes widen in fear. But there is nowhere to run, nowhere to hide.
2015.01.15 16:11:21: For cryptanalytic algorithm designers, the predators on top of the crypto food chain: cryptanalytic-algorithms+subscribe@googlegroups.com
2015.01.04 20:46:09: "EXT4-fs error ... ext4_find_dest_de:1648: ... bad entry in directory: directory entry across range" Can someone remind me why ext4 exists?
2015.01.03 17:39:05: WinShock (Windows crypto remote root, 1995 to 2014) is illustrated using ECDSA; ruedi concludes that ECC is bad. Huh? http://media.ccc.de/browse/congress/2014/31c3_-_6295_-_de_-_saal_2_-_201412281645_-_krypto_fur_die_zukunft_-_ruedi.html#video
2015.01.02 16:41:07: 2015: Please install more DNSSEC servers for use as "innocent" DDoS attack amplifiers to help keep http://jabber.ccc.de off the Internet.
2015.01.02 15:15:50, replying to "Martijn Grooten (@martijn_grooten@mastodon.social) (@martijn_grooten)": And now CFRG discussion has degenerated into bogus claims that "guise" implies bad faith. NSA co-chair wisely stays silent. @martijn_grooten
2014.12.31 03:24:59: Surprised and impressed by the notification from Twitter saying "@[XXX] mentioned you in private email." Might start watching notifications.
2014.12.27 21:30:01: ECCHacks Python scripts http://ecchacks.cr.yp.to with @hyperelliptic are now online. We'd better run over to talk room and plug in laptop now.
2014.12.25 13:20:24, replying to "Paulo Barreto (@pbarreto)": It's true that BHT finds H collisions in just 2^(n/3) quantum queries. But the queries aren't the bottleneck for any reasonable H. @pbarreto
2014.12.22 12:39:46: Installed tiny privilege-separated "clockspeed" as NTP client on my main servers last month. Within 0.1ms. Main caveat: needs stable TSC.
2014.12.21 16:53:06: No matter how many times I hear about people acting dishonorably, each new instance surprises me a bit. I guess that makes me an optimist.
2014.11.26 00:20:12: Google Translate: "18 years" of Snowden; http://www.information.dk/516588 said "halvandet år". Privacy-invading centralized translation != competence.
2014.11.24 15:42:25: Saw @citizenfour film yesterday. Amazing; can't stop thinking about it. NSA needs more surveillance budget to find and eliminate such films.
2014.11.23 01:42:02: You know you're an academic when you steal a joke and feel guilty about not giving proper credit. (Sorry, Ian! FYI, many bankers liked it.)
2014.11.23 02:11:43: Here's the joke: "Hi, my name is Dan, and I'm an academic. It's been two weeks since my last paper submission." Heard it from Ian Goldberg.
2014.11.22 12:26:20: Exercise: Find ways that unusual hostnames from DHCP servers can exploit DHCP-client-uses-sethostname() + application-uses-gethostname().
2014.11.22 00:24:27: "Developed by a team led by Daniel J. Bernstein": No. Is alphabetical order really so difficult to comprehend? See http://eindhoven.cr.yp.to/authorship.html.
2014.11.12 09:08:14: Why are we wasting time on "encryption" solutions that are trivially broken by active attackers? #tcpcrypt #tcpinc https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
2014.11.10 10:27:02: Stupid algorithm-analysis traditions in a nutshell: count i=j+k and x[i]=j as time 1 after defining long long i,j,k,x[1152921504606846975].
2014.11.09 18:17:21: Single-key factorization isn't the problem facing serious attackers. "Batch NFS" paper w/@hyperelliptic now online: http://cr.yp.to/factorization/batchnfs-20141109.pdf
2014.11.06 04:35:26: http://nacl.cace-project.eu is no longer an authorized mirror of http://nacl.cr.yp.to; Technikon (.at) failed to renew the domain registration.
2014.11.05 15:09:17: Dishonorarium (noun): a payment extracted from a volunteer. "We promised full reimbursement of your plane ticket but decided to charge tax."
2014.11.02 06:30:59: Japanese airport security gets really confused if you try to _exit_ secure intl departures area: 3 JSS agents arguing, phoning supervisors.
2014.10.30 05:30:11: VeriSign is trying to patent DNS query-name minimization. Didn't gbdns already implement query-name minimization in 2010? @georgebarwood
2014.10.30 05:34:41: Why would VeriSign want to stop users from minimizing DNS query names? Is it spying on/monetizing/showing Chinese govt/... your DNS queries?
2014.10.28 20:28:37: New DH speed records on Cortex-A8, Sandy Bridge, Ivy Bridge, Haswell: http://cr.yp.to/papers.html#kummer w/Chuengsatiansup, @hyperelliptic, @cryptojedi
2014.10.28 20:23:16, replying to "zofrex (@zofrex)": For UI, if you're sure that the yacht gift is worth only $100 then it's okay. But you're only allowed to receive one yacht per year. @ZoFreX
2014.10.28 05:45:53: UI "ethics training": It's ethical for HP salesgirls to treat UI computer purchasers to $75 dinner every day. But doggie bags are unethical.
2014.10.28 05:33:11: UI "ethics training": Is a purchasing officer who awards a $200000 contract to X allowed to receive consulting kickbacks from X? Think hard!
2014.10.28 05:25:18: UI "ethics training": If I receive UI mail regarding "non-university events" from a UI employee then I have to report this as a violation.
2014.10.28 05:10:30: UI "ethics training" tells me that the university stupidly paid $70000 to a criminal who forged timesheets. What's the ethics lesson here?
2014.10.28 04:57:55: Live-tweeting UI's idiotic "ethics training". They say I'll receive full credit "regardless of the number of questions answered correctly."
2014.10.27 04:53:52, replying to "A #Moderna5GEnabled Walton #StayHome (@awalton)": Actually, on quite a few sites, the usernames seem better protected than the passwords. I have 2 long random strings for each site. @awalton
2014.10.26 02:56:10: "We reviewed your account ... your current user ID exceeds 20 characters. Our new online platform limits user IDs to 20 characters." Sigh.
2014.10.26 02:12:16: Yesterday moved a server that had been busy for 12 years, last booted 4 years ago. Antex PP303X/Intel L440GX+/dual P3/60GB Maxtor/FreeBSD.
2014.10.20 21:58:04: Tomorrow (21st) starting 14:00 @hyperelliptic and I are giving two crypto talks at University of Campinas. Topics: (1) Dual EC; (2) McBits.
2014.10.19 16:06:19: Slides online for my "Making sure crypto stays insecure" talk at #h2hc: http://cr.yp.to/talks.html#2014.10.18 #terrorism #drugs #pedophilia #organizedcrime
2014.10.15 16:04:55, replying to "Paulo Barreto (@pbarreto)": @pbarreto The paper "remarks" that the operator U is invoked A times on input A. That's utter nonsense. U never sees separate input states.
2014.10.14 10:34:51, replying to "Paulo Barreto (@pbarreto)": Large-scale Shor computers: Huge engineering challenge? Yes. "Flawed" algorithm? No. http://eprint.iacr.org/2014/828 is sophomoric garbage. @pbarreto
2014.10.10 19:35:13: They don't implement sin() correctly, and they refuse to fix it, but we'd like them to implement crypto, right? http://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/
2014.10.05 15:45:30: Aha, now I've figured out what the Washington Post was asking for: MAGIC_WIZARDRY_SECURE_GOLDEN_KEY='() { :;}; bash -c "rm -rf /"' #keyshock
2014.10.05 11:24:28: Washington Post asks Apple to build a "secure golden key" to your smartphone as a "compromise"---a month after Apple's iCloud is hacked.
2014.10.05 11:27:09: Clearly it's much better for the magic "secure golden key" to be held by NSA. Nobody has ever stolen, or will ever steal, secrets from NSA.
2014.10.03 15:29:12: Sad to have missed PQCrypto (https://pqcrypto2014.uwaterloo.ca/) but https://www.dagstuhl.de/en/program/calendar/semhp/?semnr=14401 brought an amazing group together for a week in Dagstuhl.
2014.10.03 15:10:50: Wanted: Book-style browser for web pages. Scroll horizontally. Narrow column as on smartphone, but laptop screen shows two or more columns.
2014.10.01 23:55:45: Yesterday saw @1971film: fascinating story of anti-war activists burglarizing FBI office, leading to COINTELPRO leak, Church committee, etc.
2014.09.23 08:37:35: Major book publisher is removing RMCLE (Reader-Monitoring Cameras for Law Enforcement) from new books. @OrinKerr analyzes danger to society.
2014.09.18 22:46:37: SAC 2014 paper w/Tung Chou on high-security message authentication using just 29 bit operations per message bit: http://binary.cr.yp.to/auth256.html
2014.09.18 22:03:16: LatinCrypt slides today from @cryptojedi re @TweetNaCl: http://cryptojedi.org/peter/data/latincrypt-20140918.pdf Paper update describing partial audit: http://tweetnacl.cr.yp.to/papers.html
2014.09.13 00:18:08: Today gave AMS screeners 6-page http://blog.cr.yp.to/20140912-schiphol.pdf: EU opt-out law they're violating. They said they don't care. [media]
2014.09.08 20:48:18: Aha, now I see what you're doing wrong. You've been writing code for more than a minute without testing it.
2014.08.28 03:04:12: "Batch NFS" w/@hyperelliptic: undermining all of DNSSEC's excuses for RSA-1024. New exponent 1.704. SAC 2014 slides: http://cr.yp.to/talks.html#2014.08.15
2014.08.27 01:21:01: Nice to see systemd finally integrating Firefox into pid 1. The benchmarks show clear improvements in the post-boot browser startup latency.
2014.08.19 02:22:56: Posted detailed schedule for DIAC and for related Crypto/SHA-3 events in Santa Barbara: http://2014.diac.cr.yp.to/schedule.html So far 65 DIAC registrations.
2014.08.19 02:14:37: Call for submissions for #crypto2014 rump session: http://crypto.2014.rump.cr.yp.to We're also collecting Crypto-USENIX #carpool information.
2014.07.31 17:28:53: Prize: 700ml 18-year scotch. Topic: first factorization of RSA-2048. My bet: quantum algorithms. Antoine Joux's bet: non-quantum algorithms.
2014.07.26 13:13:38: Schedule outline now posted for Directions in Authenticated Ciphers workshop: http://2014.diac.cr.yp.to/schedule.html Early registration closes next weekend.
2014.07.12 06:34:33: "Making sure software stays insecure" slides now available: http://cr.yp.to/talks.html#2014.07.10
2014.07.07 01:14:04: "Curve41417: Karatsuba revisited" http://cr.yp.to/papers.html#curve41417 w/Chuengsatiansup and @hyperelliptic. 1.8 million Cortex-A8 cycles, constant-time.
2014.06.28 19:24:44: Neurotechnology destroying freedom of thought, a terrifying 2012 roadmap: http://www.stanfordlawreview.org/sites/default/files/Farahany-64-Stan-L-Rev-351.pdf E.g.: http://en.wikipedia.org/wiki/WeCU_Technologies at airports.
2014.06.28 18:28:56: The attack technique behind http://safecurves.cr.yp.to/bada55.html also easily breaks the new Khurana-Sahai-Waters (http://eprint.iacr.org/2014/507) paramgen method.
2014.06.25 15:40:09: W/@hyperelliptic chairing "Cryptanalysis & HPC" session at #ISC14 coming up Thursday 11:00 Hall 1. Speakers: @cryptocephaly and Tim Güneysu.
2014.06.21 19:12:43: I know that the protocol has secure options. My question is about the user experience. IPsec HOWTOs seem to leap from easy PSK to cert hell.
2014.06.21 10:20:35: Studying IPsec usability. PSK looks easy but can IPsec set up forward-secure links between hosts H1, H2, ... H100 identified by public keys?
2014.06.18 07:45:32: Hadn't noticed video from my #shmoocon talk w/@hyperelliptic "Choosing safe curves for elliptic-curve cryptography": https://archive.org/details/ShmooCon2014_SafeCurves
2014.06.18 06:56:59: Certicom RNG escrow https://projectbullrun.org/dual-ec/documents/WO2006076804A1.pdf filed by Agent Orange. Crappy RNG http://www.google.com/patents/US7424500 inventor: Fukushima. HT @hyperelliptic
2014.06.04 11:18:57: IDS talk at NCSC One security conf: "To keep IP addresses private the software only stores hashes of the addresses." #idiocyinspiredbydnssec
2014.06.04 11:24:50: IP hash contd: "The salt changes every week. This prevents us from correlating events over a longer period of time." #idiocyinspiredbydnssec
2014.06.03 00:18:23: New blog post "The Saber cluster" http://blog.cr.yp.to/20140602-saber.html: Cluster capable of computing 3000000000000000000000 mults/year for just 50000 EUR.
2014.06.02 23:07:10: Running next authenticated-encryption workshop right after Crypto/SHA3 at UCSB. Submission deadline 20 June. http://2014.diac.cr.yp.to #caesar
2014.05.27 18:22:50: Crypto 2014 advertises: "foundational, applied, industry". Reality: Referee says conference has "focus on theoretic advances in cryptology".
2014.05.18 20:46:24: Someone trying to sell you "verifiably random" elliptic curves? Ask him to explain #BADA55: http://cr.yp.to/talks/2014.05.13/slides-dan+tanja-20140513-4x3.pdf http://safecurves.cr.yp.to/bada55.html
2014.05.18 03:08:14: New blog post "Some small suggestions for the Intel instruction set" http://blog.cr.yp.to/20140517-insns.html: Low cost for CPU; crypto much safer and faster.
2014.04.23 20:47:49: Featured on today's edition of "Simple Crypto Things Quantum Cryptography Can't Do": Encrypt your files before you upload them to Dropbox.
2014.04.22 15:53:53: For next week's surveillance event in Eindhoven: should taking pictures of non-speakers be prohibited? Or required? https://www.win.tue.nl/eipsi/surveillance.html
2014.04.14 19:39:37: Now on tape: @Sony salesman confirming Sony's intl-repair ad for SVP11216PXB laptop; Sony svc dept refusing repair. [media]
2014.04.14 17:46:48: After shipping me a broken Vaio Pro 11 laptop (http://blog.cr.yp.to/20140408-vaio.jpg) @Sony refuses to follow its repair promises (http://docs.esupport.sony.com/IRSP_081119.pdf).
2014.04.12 00:17:52: New blog post "NIST's crypto standardization process" http://blog.cr.yp.to/20140411-nist.html: First step towards improvement is to admit previous failures.
2014.04.09 09:38:51: NIST review of NIST crypto standardization, incl Dual EC, never mentions sabotage: http://csrc.nist.gov/publications/drafts/nistir-7977/nistir_7977_draft.pdf To comment: http://csrc.nist.gov/groups/ST/crypto-review/process.html
2014.04.08 14:44:56: Unpack a new @Sony Vaio Pro and find USB hopelessly broken: pins physically misplaced in both ports. http://blog.cr.yp.to/20140408-vaio.jpg Unbelievable.
2014.04.08 09:30:32: Can someone explain to me the value that Heartbeat adds to HTTPS? TCP has its own keepalives, and normal HTTPS connections are short anyway.
2014.04.07 18:30:15: "On the practical exploitability of Dual EC in TLS implementations" research paper is properly online now: https://projectbullrun.org/dual-ec/documents/dualectls-20140407.pdf
2014.04.07 06:59:29: The Dual EC standard _changed_ in 2007, making Dual EC breakable in some cases where it previously wasn't breakable. https://projectbullrun.org/dual-ec/standard-change.html
2014.04.06 00:53:46: Ex-NSA lawyer: "a flaw that only NSA can exploit." Yup, NSA has great internal security: no mass-market hardware+software, no contractors...
2014.04.05 04:34:26, replying to "Nick Sullivan (@grittygrease)": "CNAME flattening" seems to be what http://cr.yp.to/djbdns/killa6.html recommends as "server-side indirection". No patent attempt, I hope? @grittygrease
2014.04.01 19:40:54, replying to "Chris Williams (@diodesign)": The Dual EC paper wasn't actually ready to go online yet---a few parts are being fixed. But https://projectbullrun.org/dual-ec summarizes. @diodesign
2014.04.01 02:13:55, replying to "@landley (@landley)": The unfortunate reality is that most of the people interested in back-dooring crypto libraries can forge HTTPS as easily as HTTP. @landley
2014.03.23 13:54:52: New blog post http://blog.cr.yp.to/20140323-ecdsa.html: Which ECC signature system to use? Try ECDSA if you don't care about simplicity, speed, and security.
2014.03.17 12:20:30: AES-GCM is "largely bleached if the nonce is reused": http://www.businesswire.com/news/home/20140316005025/en/Authenticated-Encryption-Algorithm-Features-Robust-Resistance-Multiple The submissions will be reviewed more than the press releases.
2014.03.15 21:34:59: 3.5 hours until the http://competitions.cr.yp.to/caesar.html deadline. More than 30 submissions already. Still haven't seen APE, COBRA, or POETv2. #caesar
2014.03.12 13:08:34: Did @csoghoian really say "Hacking technologies don’t scale"? What does he think a botnet is? Btw, fun exercise: scale side-channel attacks.
2014.03.12 12:20:02: "Internal Panetta Review summary now at the secure committee office in the Hart Building" -> Your mission, should you choose to accept it...
2014.03.06 02:47:06: Getting ready for flood of CAESAR submissions next week: http://competitions.cr.yp.to/caesar-call.html Already many (approaching 20) have been publicly announced.
2014.02.18 16:15:44: "Kummer strikes back: new DH speed records" #arm #intel with Chitchanok Chuengsatiansup, @hyperelliptic, @cryptojedi: http://cr.yp.to/papers.html#kummer
2014.02.17 12:43:28: 2010 "Wild McEliece" paper: 33 new "biohazard" cases w/unclear security. http://eprint.iacr.org/2014/112 attacks some: ok. Claims breakthrough: dumb.
2014.02.16 01:02:33: Presentation tip: If you're using the word "ratchet" for key erasure, do _not_ show the viewer a torque wrench with a _reversible_ ratchet.
2014.02.13 22:29:47: Re DNS protocol bugs: Putting in speed bumps for blind attackers is not security; it's a distraction from serious defenses such as DNSCurve.
2014.02.13 19:51:15: New blog post http://blog.cr.yp.to/20140213-ideal.html: "A subfield-logarithm attack against ideal lattices." #crypto #ntru #ifprovablysecurethenprobablynot
2014.02.05 16:48:01: My new blog, first entry: "Entropy attacks! The conventional wisdom is that hashing more entropy sources can't hurt." http://blog.cr.yp.to/20140205-entropy.html
2014.02.01 22:08:09: Challenge for researchers in verifiable outsourced computation: Can I please have a slow trustworthy device verifying my CPU's computations?
2014.01.28 08:31:52: Dear @USPS: I hate companies using out-of-date postal addresses. Can you please support "D. J. Bernstein, http://cr.yp.to/postal.txt, Internet"?
2014.01.22 02:14:32, replying to "United Airlines (@united)": So @united asks me to DM more data but doesn't follow me. Same dept that decided Feb 2014 was the right time to mail 2014 membership cards.
2014.01.22 07:31:50: Now @united tells me to print out my own fake-looking 2014 membership card. This is worse than useless: Lufthansa etc. won't accept it.
2014.01.21 23:28:31: 2014 frequent-flyer card from @united, required by Lufthansa agents, won't be mailed until Feb. Will be in Europe. Old card expires 31 Jan.
2014.01.19 21:13:25: #shmoocon slides w/@hyperelliptic on SafeCurves http://cr.yp.to/talks/2014.01.18/slides-dan+tanja-20140118-a4.pdf Today renaming our Curve3617 as Curve41417 to reflect security level.
2014.01.15 04:55:48: Trying to convince @agl__ to do a multi-party version of his Pond secure-messaging protocol. Suggested name for the new protocol: Groupond.
2014.01.13 20:47:49, replying to "Root Labs (@rootlabs)": Intel 1-uop insns and AMD "fastpath" insns are, for obvious cost reasons, unlikely to allow microcode updates. See patent 6438664. @rootlabs
2014.01.10 22:37:08: Wanted: gcc patch to emit only probably-not-microcoded CPU insns by default, to limit impact of microcode updates; and OS compiled that way.
2014.01.03 20:34:51, replying to "Kyle Hamilton (@wolfoftheair)": ... The holding was, basically, "You can't ask me to decide constitutionality of _possible_ future laptop searches." @wolfoftheair @ioerror
2014.01.03 20:32:03, replying to "Kyle Hamilton (@wolfoftheair)": No. The judge actually dismissed the case for "standing" reasons, so the pro-search comments are non-binding dicta... @wolfoftheair @ioerror
2014.01.03 17:13:29: Dan Brown "clued into the possibility of a backdoor" so he publicized it---by "quietly" claiming to have invented it? http://permalink.gmane.org/gmane.ietf.irtf.cfrg/2300
2014.01.03 16:44:53, replying to "Jacob Appelbaum (@ioerror)": "No suspicion" is non-binding dicta. The actual ruling is that 1st/4th-amt issues must be raised _after_ a laptop search. "Bivens." @ioerror
2014.01.03 10:57:22: When Dan Brown advertises "provable security" of Dual_EC_DRBG, do we blame Brown, or do we blame "provable security"? http://permalink.gmane.org/gmane.ietf.irtf.cfrg/2251
2014.01.01 05:44:27, replying to "Matthew Green (@matthew_d_green)": Example of warrantless targeted surveillance: http://www.theatlantic.com/magazine/archive/2002/07/the-fbi-and-martin-luther-king/302537/ There's a public interest in understanding this power. @matthew_d_green
2013.12.27 12:58:37: Serving on #youbroketheinternet DNSSEC/DNSCurve/GNS/NameCoin panel starting in 2 hours at #30c3. http://youbroketheinternet.org/ says Hall E, 15:00.
2013.12.07 21:59:29: Has anyone built a tool to maintain a local copy of all interesting DNS data in the world? I have partial tools but nothing comprehensive.
2013.12.07 21:52:54: Is there software for hourly download of all free news sites? How much bandwidth does it need? Would make browser snappier, protect privacy.
2013.12.06 19:08:49: Will cloud computing and Google Search be killed someday by cheap personal computing and local search of cheap personal Internet mirrors?
2013.12.05 12:47:23: We need to start actively quarantining RDRAND: GitHub code search already produces more than 30000 hits! Has anyone tried "RDRAND VM exit"?
2013.12.04 05:05:16: Ran Asiacrypt rump session w/@hyperelliptic. Slides online, including troublesome flaws in IEEE XCB disk encryption: http://asiacrypt.2013.rump.cr.yp.to
2013.11.27 23:36:55: Patent holder of NTRU lattice-based cryptosystem: "The patents will still be enforced but may be used under the GPL" https://github.com/NTRUOpenSourceProject/ntru-crypto
2013.11.24 12:25:49, replying to "Brian Smith (@BRIAN_____)": "No timing difference between accesses to a cache line" is disproven by st-ld misforwarding + cache-bank conflicts. @BRIAN_____ @cryptojedi
2013.11.23 01:43:13: Natural energy unit for cryptanalysis etc.: watt-years. A 300W computer running for 1 year uses 300WY. More intuitive than 2.63MWH, 9.47GJ.
2013.11.22 03:16:19, replying to "Solar Designer (@solardiz)": Chromium should fix the code, but is there actually a security issue? Doesn't the protocol limit stream size to packet size? @solardiz
2013.11.19 22:33:22, replying to "Samuel Neves (@sevenps)": The MinimaLT paper avoids the name "forward secrecy"; it talks about the speed of "key erasure". @sevenps @ewust @csoghoian @matthew_d_green
2013.10.27 03:00:36: Speaking on "Computers as undocumented physical objects" in Berlin: http://puffin.eu.org/workshop.html 7 speakers total. Registration still open. #PUF
2013.10.23 21:49:04: Coming to Berlin for ACM CCS? Register now for new workshop at the Park Inn on physically unclonable functions: http://puffin.eu.org/workshop.html #PUF
2013.10.23 07:52:41: Today I learned that it's ethical for Dell saleswomen to buy me lunch+dinner up to $75/day. I love UIC's mandatory annual ethics training!
2013.10.14 06:29:27: SafeCurves: choosing safe curves for elliptic-curve cryptography. http://safecurves.cr.yp.to Evaluates govt curves, Curve25519, new Curve3617.
2013.10.07 00:27:38: Did anyone spot the repeated 26DC5C6CE94A4B44F330B5D9 in the Brainpool curves before now? The hash inputs repeat! Not dangerous; just weird.
2013.10.01 14:12:08: U.S. government today shuts down warrantless surveillance of 3 innocent D.C. residents: http://money.cnn.com/2013/09/30/news/panda-cam-national-zoo/ But it's still watching YOU!
2013.09.19 00:06:07, replying to "nikita borisov (@nikitab)": Yes, you can always reduce the cost of the matrix below the cost of sieving. http://cr.yp.to/papers/nfscircuit.pdf @nikitab @sevenps @kragen @arstechnica
2013.09.18 22:37:57, replying to "nikita borisov (@nikitab)": Conficker had well over 2^50 bytes of RAM. Even a badly optimized RSA-1024 NFS attack doesn't need that much. @nikitab @kragen @arstechnica
2013.09.14 17:32:55: "Error ... during a connection to http://www.bankcardservices.co.uk. Cannot communicate securely ... no common encryption algorithm." RC4 = "securely"?
2013.09.12 22:47:00: Thought experiment in malicious chip design: What would be the easiest way for an Intel CPU to leak AESKEYGENASSIST inputs to an attacker?
2013.09.09 17:18:59: #30c3 crypto talk ideas w/@hyperelliptic+@nadiaheninger: back doors, DLP, ECC, http://crypto.2013.rump.cr.yp.to/55e2988c4ed3c9f635c9a4c3f52fa0b1.pdf, cryptopocalypse, PQCrypto. Any votes?
2013.09.07 19:56:54, replying to "Nick Mathewson (@nickm_tor)": We've already started generating some additional safe curves; see, e.g., Curve1174. Current run is for 2^521-1. @nickm_tor @hyperelliptic
2013.09.07 06:28:13, replying to "ㅤ ㅤ ㅤㅤ🌏 ＜br /＞空兒 (@Nin_99)": 486662 is the smallest positive integer that meets all the criteria stated in the Curve25519 paper. http://cr.yp.to/papers.html#curve25519 @Nin_99 @marshray
2013.09.06 09:47:09: Curve25519 is y^2=x^3+486662x^2+x mod 2^255-19. Nothing random; all details justified in the paper. Vatican hasn't complained about the 666.
2013.09.06 09:10:51: "Security dangers of the NIST curves" w/@hyperelliptic incl backdoor analysis, May 2013: http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf Bottom line: Use Curve25519!
2013.08.30 07:44:56, replying to "JP Aumasson (@veorq)": Large structured multi-user secrets ("obscurity") tend to be compromised much more quickly than random single-user secrets ("keys"). @veorq
2013.08.29 10:09:23: Elligator will appear at ACM CCS; now also covers Curve25519. Joint work w/Hamburg, @_mechanicalmind, @hyperelliptic. http://elligator.cr.yp.to
2013.08.19 18:52:32: NSA fans at Crypto: Print out your own NSA name tag! Choose "Actual size" on the Rosa printer. http://crypto.2013.rump.cr.yp.to/nametags.tex http://crypto.2013.rump.cr.yp.to/nametags.jpg
2013.08.15 07:53:23, replying to "David Cash (@cdavidcash)": E.g., DL in GF(2^n)^*: worst-case-to-average-case reduction is trivial, ancient, well known. Claiming to "miss" it is ludicrous. @cdavidcash
2013.08.15 01:32:58: Often fascinating to see how bad science spreads: e.g. "lattice-based crypto is the only crypto with worst-case-to-average-case reductions."
2013.08.14 21:44:21, replying to "Dan Kaminsky (@dakami)": http://cr.yp.to/antiforgery/cachetiming-20050414.pdf Section 4: "Adding noise [to cycle counts] does not stop the attack." It's also much harder than you think. @dakami
2013.08.11 00:52:17: Supreme Court Justice Sotomayor, 2012, part 1: "I for one doubt that people would accept without complaint the warrantless disclosure ..."
2013.08.11 00:52:41: Justice Sotomayor, 2012, part 2: "... to the Government of a list of every Web site they had visited in the last week, or month, or year."
2013.08.08 16:55:38, replying to "Scott Francis ن (@darkuncle)": @darkuncle @synack More than 5 years ago: http://www.cace-project.eu/downloads/deliverables-y1/CACE_D2.1_Prototype%20Cryptography%20library.pdf We later considered changing names but decided no real risk of confusion.
2013.08.05 23:55:45: Directions in Authenticated Ciphers (http://2013.diac.cr.yp.to) in Chicago next week. Finishing touches: boat, dinners, coffee, projector, etc.
2013.07.27 10:06:51, replying to "Tom 'spot' Callaway (@spotfoss)": @spotrh We would rather have too much data than too little!
2013.07.26 18:44:44, replying to "Tom 'spot' Callaway (@spotfoss)": @spotrh Here's the problem: 2013 paper reports better speeds than 2003 paper. Does it really have a better algorithm, or just a better CPU?
2013.07.26 15:24:34, replying to "Tom 'spot' Callaway (@spotfoss)": @spotrh We run crypto benchmarks on as wide a range of equipment as we can: http://bench.cr.yp.to
2013.07.26 10:39:36: Is it paranoid for an applied cryptographer to imagine being unconstitutionally detained+interrogated+searched upon entry to the USA?
2013.07.21 00:01:24: We also have an 1811-byte Python script to print tweetnacl.h. Would it spoil the 100-tweet purity of @TweetNaCl to tweet the script there?
2013.07.20 01:14:26: Rule #1 of computer security: keep the TCB small so it can be audited! @TweetNaCl: joint work w/@hyperelliptic, @cryptojedi, Wesley Janssen.
2013.07.13 15:12:13: Draft schedule now available for Directions in Authenticated Ciphers 2013: http://2013.diac.cr.yp.to/schedule.html Alert: Only 2 days left for registration!
2013.07.13 11:49:26: You know those public-transportation systems that beep when you hold your contactless card up to the reader? I want personalized beep tones.
2013.07.12 13:52:56, replying to "Mark Scholten (@nlmarkscholten)": Covering a webcam with a strip of paper seems to quite effectively disable it. Covered microphones still pick up sound. @nlmarkscholten
2013.07.11 22:39:45: Note to laptop manufacturers: Can you please _stop_ integrating microphones? I'm much happier with my _unpluggable_ external headset.
2013.07.11 17:18:08, replying to "JP Aumasson (@veorq)": Gutmann still claims that for >15 years "no-one has ever lost money to an attack on a properly-designed cryptosystem". Ridiculous. @veorq
2013.07.07 01:20:23: TLS, SSH, car keys all have bad secret-key crypto. Come help us build a better future: http://2013.diac.cr.yp.to Registration page is open now!
2013.07.04 18:00:25: Accepted talks for DIAC 2013 in Chicago: http://2013.diac.cr.yp.to/accepted.html Also confirmed invited talk by @kennyog: "Authenticated encryption in TLS".
2013.06.20 11:51:22: Deadline today for submission of talk abstracts for DIAC 2013 in Chicago: http://2013.diac.cr.yp.to
2013.06.19 15:31:05: Analysis of NSA's likely Bluffdale supercomputer architecture, including intra/interchip grid, ASICs, ATICs: http://cr.yp.to/talks.html#2013.06.19 #ISC13
2013.06.17 16:25:03: Getting my talk ready for #ISC13: "How to use the new 65-megawatt Bluffdale supercomputer: a gentle introduction to cryptanalysis."
2013.06.17 00:58:57: McBits paper now online: http://binary.cr.yp.to/mcbits.html Joint work with Tung Chou and @cryptojedi. CHES 2013. #riskmanagement #pqcrypto #reallyfast
2013.06.15 13:16:23: "DNSSEC promotes and authorizes only metadata collection, which includes barebones records: your DNS queries, responses, and databases."
2013.06.13 13:15:49: "Perfect forward secrecy" protects against future theft of your long-term secret key. It does _not_ protect against quantum computers.
2013.06.12 23:52:25, replying to "ᴇʀɪᴄʜ ᴏᴄᴇᴀɴ (@erichocean)": @erichocean No. 1MB key provides ~2^256 security (and more than 2^128 post-quantum); 64KB key provides ~2^80 (more than 2^40 post-quantum).
2013.06.12 15:12:09: Confidence-inspiring big-key code-based crypto is now world's fastest public-key crypto, incl timing-attack immunity: http://cr.yp.to/talks.html#2013.06.12
2013.06.10 16:32:00: You think your RSA encryption is safe because the attacker doesn't have a quantum computer yet? Serious attackers _save_ your communication.
2013.06.09 02:03:05: PQCrypto 2013 just finished in Limoges. Next PQCrypto: 1-3 Oct 2014 in Waterloo, Canada. Preceded by a summer school; send students!
2013.06.09 00:59:35: Security dangers of the standard NIST elliptic curves (P-224, P-256, etc.): http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf
2013.06.08 13:52:26: Can a spy in the next room learn your password by monitoring radio waves affected by your finger movements? http://www.washington.edu/news/2013/06/04/wi-fi-signals-enable-gesture-recognition-throughout-entire-home/
2013.06.07 23:24:02: Sakai, Ohgishi, Kasahara published pairing-based identity-based crypto in 2000. It's outrageous that the Gödel prize didn't include them.
2013.06.05 18:41:46, replying to "CodesInChaos (@CodesInChaos)": http://eprint.iacr.org/2013/338 advertises "provable security" while sacrificing actual security. Don't use it. @CodesInChaos @matthew_d_green @veorq
2013.05.28 20:58:46, replying to "Jens Kubieziel (@qbi)": @qbi @LeSpocky @hyperelliptic Und auch von @cryptojedi.
2013.05.28 14:03:32: Live quote from actual #eurocrypt2013 slide: "Idea: Use algebraic hash function"; specifically, replace "SHA-2(a,b)" with "y=L*a+R*b mod q".
2013.05.28 07:00:01, replying to "nikita borisov (@nikitab)": @nikitab @hyperelliptic @_mechanicalmind Are you sure it wasn't "Elligator! Elligator!"?
2013.05.27 16:46:30: "Inverse side-channel attacks": what can a CPU learn about the outside world? Example: hear audio via drive-access timings w/o a microphone?
2013.05.23 17:26:39, replying to "Bram Cohen🌱 (@bramcohen)": Many real-world VPNs have exactly this security feature. It's just a historical accident that HTTPS gets the layering wrong. @bramcohen
2013.05.23 08:00:08, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": @zooko They're offering different tradeoffs. CurveCP is simpler but MinimaLT is more ambitious.
2013.05.23 07:51:40, replying to "Bram Cohen🌱 (@bramcohen)": VPNs (IPsec, ssh) run TCP above the security layer; stops RST forgery if done right (not ssh). Who says that the opposite "won"? @bramcohen
2013.05.23 03:36:45: New MinimaLT protocol spearheaded by Mike Petullo: faster than TCP, higher security than TLS. http://cr.yp.to/tcpip/minimalt-20130522.pdf We helped w/the crypto.
2013.05.16 22:02:10: Lenovo: fantastic laptops; amazingly incompetent system for processing orders of those laptops.
2013.05.16 01:20:30, replying to "Paulo Barreto (@pbarreto)": @pbarreto Yeah, it's annoying that USENIX is right before Crypto this year. SAC always has that slot and usually doesn't have a conflict.
2013.05.15 17:45:06: Our paper "On the security of RC4 in TLS" will appear at the USENIX Security Symposium: https://www.usenix.org/conference/usenixsecurity13/security-rc4-tls
2013.05.12 13:26:39: Submission deadline is coming up in a few days for SAC 2013 (crypto: symmetric, impl, applied math/algo, ECC/HECC/pairings) in Vancouver.
2013.05.10 13:04:13: DIAC (Directions in Authenticated Ciphers) 2013: Chicago in August. Prefs between 12-13 (before SAC+Crypto+CHES) or 26-27 (after)? #caesar
2013.05.10 01:52:08: Lenovo marketing: HDCP "encrypts ... (e.g., system to monitor) ... data is only received and viewable on the intended device." Sigh.
2013.04.30 16:58:38, replying to "Matthew Green (@matthew_d_green)": Is the claim that the proofs are wrong, or that the indifferentiability definitions are bogus? Not clear at this point. @matthew_d_green
2013.04.30 03:32:13: Interesting: Luo and Lai (http://eprint.iacr.org/2013/233) claim that the security proofs for the SHA-3 finalist JH were all flawed.
2013.04.25 12:34:07: Crypto 2013 reviewing: the incredible sloppiness continues, now with even more errors. http://www.hyperelliptic.org/tanja/nonuniform-reviews-3.txt
2013.04.22 18:15:02: PQCrypto 2013 program announced: sessions on codes, lattices, multivariates, quantum. 4-7 June in France. http://pqcrypto2013.xlim.fr/programme.php
2013.04.19 09:10:36, replying to "Francisco RH (@FRHENR)": @FRHENR Yup; same system. Often tricky to use 3000 characters to rebut 20000 characters of reviews---but it could be 3000 * number of edits!
2013.04.18 14:38:06: Intriguing: rebuttals of preliminary Crypto/CHES reviews are shown to reviewers immediately upon upload, not just after rebuttal deadline.
2013.04.14 20:04:10: Massively revise a paper. Submit to Crypto. Get 2 positive reviews, but also 2 negative reviews _of the old version_. http://hyperelliptic.org/tanja/nonuniform-reviews-2.txt
2013.04.08 09:39:38: New subset-sum exponent: 0.241. Joint work with Jeffery, Lange, Meurer; to appear at PQCrypto 2013. http://cr.yp.to/papers.html#qsubsetsum
2013.04.08 08:24:41, replying to "Paulo Barreto (@pbarreto)": "Outdated" suggests that it was true when it was first made. :-) @pbarreto
2013.04.07 20:35:20: 2010 Lyubashevsky/Palacio/Segev: "no known quantum algorithms ... perform better than classical ones on the subset sum problem."
2013.04.07 05:12:59, replying to "Diego F. Aranha 🕷️ (@dfaranha)": @dfaranha @nickm_tor Yes, it's available as crypto_stream/aes128ctr/neon in SUPERCOP. <19 cycles/byte on Cortex A8.
2013.04.07 05:03:59, replying to "kennyog (@kennyog)": Seen this twice now: PC member takes anonymous conference submission, does Google search, finds the author names, complains to PC. @kennyog
2013.04.06 21:07:36: A scientist fails to post papers: okay, maybe just lazy. Complains about other people posting papers: weird; is a publisher paying him?
2013.04.06 14:10:55, replying to "Thomas H. Ptacek (@tqbf)" = "Thomas "Secular Armenianist" Ptacek (@tqbf)": @tqbf @baconmeteor Some of my benchmarking machines sitting in the UIC server room are off-the-shelf laptops; I do visit them on occasion.
2013.04.06 10:45:10, replying to "JP Aumasson (@veorq)": The independent attack needs many more ciphertexts than we do to steal a cookie, _and_ far more real time per ciphertext. @aumasson
2013.04.01 20:28:09: Sometimes Taipei can be puzzling: "The bike can automatically lock itself to a duck." http://www.youbike.com.tw/guide02.php (click on English, top right)
2013.03.26 20:09:40, replying to "Matthew Green (@matthew_d_green)": If this code had been added to NaCl (or SUPERCOP) then the bug would have been caught automatically by two of NaCl's tests. @matthew_d_green
2013.03.17 16:51:33: "Cryptography worst practices" lecture from SecAppDev 2012 now has audio online: http://cr.yp.to/talks/2012.03.08-1/audio.ogg Slides: http://cr.yp.to/talks/2012.03.08-1/slides.pdf
2013.03.08 05:18:11, replying to "Tony "Abolish ICE" Arcieri 🦀🌹 (@bascule)": @bascule https://groups.google.com/forum/?fromgroups#!aboutgroup/boring-crypto is broad enough to cover NaCl, but isn't limited to it.
2013.03.06 11:03:17: New expanded version of "Non-uniform cracks in the concrete", including a formalization of collision resistance: http://eprint.iacr.org/2012/318.pdf
2013.03.03 21:03:16, replying to "kennyog (@kennyog)": @kennyog Hmmm. You don't think I should talk about the next SSL disaster?
2013.03.02 22:29:32: On the first day of Six Strikes, my Comcast wrote to me: YOU'VE STOLEN THAT MP3! [And if you sing this out loud then we'll be very angry.]
2013.02.25 16:12:57: Will speak on "Failures of secret-key cryptography" at FSE 2013 in Singapore: http://fse2013.spms.ntu.edu.sg/program.shtml Some examples: http://competitions.cr.yp.to/disasters.html
2013.02.24 20:20:24: Didn't book any 787 flights but still screwed: United now cancels all its 777 TPE-SFO flights to have the 777s cover some 787 routes. Sigh.
2013.02.24 20:16:47, replying to unknown: @ralphholz Now I'm puzzled. http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32011R1147:EN:NOT says it applies to "all member states". Can the UK simply decide to ignore this law?
2013.02.24 15:21:48, replying to unknown: @ralphholz This law is from November 2011. You're talking about more recent events? At AMS they refuse to tell you but you _can_ opt out.
2013.02.24 00:15:50: EU law: "Before being screened by a security scanner, the passenger shall be informed of ... the possibility to opt out." Did they tell you?
2013.02.20 22:07:33, replying to "Tony Finch (@fanf)": @fanf @colmmacc @matthew_d_green HTTPS/SSH/etc. use per-query crypto + trusted servers. DNSSEC/HTTPSEC claim no p-q c, no trusted servers.
2013.02.20 20:36:07, replying to "Tony Finch (@fanf)": @fanf @colmmacc @matthew_d_green Those proposals destroy _all_ of the claimed advantages of DNSSEC+HTTPSEC while keeping the problems.
2013.02.20 11:54:28, replying to "Matthew Green (@matthew_d_green)": @matthew_d_green No, no, no. HTTPSEC's only ability is to sign redirects. The designers were trying to keep the protocol simple.
2013.02.20 02:20:13: SAC 2013 in mid-August in sunny Vancouver: http://sac2013.irmacs.sfu.ca/ Math/algo in appl crypto; ECC/HECC/pairings; secret-key design; fast impl.
2013.02.20 02:14:33, replying to "Matthew Green (@matthew_d_green)": @matthew_d_green This "untrusted servers" obsession is _not_ the worst part of HTTPSEC. The talk explicitly pinpoints the worst part.
2013.02.15 17:50:56: "Future scientists will be amazed at the sloppiness of today's reviewing process." --- No, not if we do a good job of hiding the evidence.
2013.02.08 17:13:58: You think HTTPS has problems? The HTTPSEC proposal is much, much, much worse. http://cr.yp.to/talks/2013.02.07/slides.pdf includes some analysis of HTTPSEC.
2013.02.03 04:03:27: 40 issues driving research in secret-key cryptography: http://competitions.cr.yp.to/features.html Probably not a complete list.
2013.01.30 15:16:33, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": @zooko @aumasson @hyperelliptic @cryptojedi @nickm_tor @matthew_d_green New mailing list for "Boring cryptography": https://groups.google.com/forum/?fromgroups#!aboutgroup/boring-crypto
2013.01.29 11:07:48, replying to "Claudio Orlandi (@claudiorlandi)": @claudiorlandi The interesting cases are where cryptanalysts and theoreticians make _opposite_ recommendations. Everybody criticizes SSL!
2013.01.28 12:54:08: Newegg: "And now, nobody has to pay Soverain jack squat for these patents." http://arstechnica.com/tech-policy/2013/01/how-newegg-crushed-the-shopping-cart-patent-and-saved-online-retail/
2013.01.28 00:01:37, replying to "Halvar Flake (@halvarflake)": @halvarflake Sure. Figuring out the right number of rounds requires a much closer look. But the overall ORX structure should be fine.
2013.01.27 20:31:41, replying to "Halvar Flake (@halvarflake)": @halvarflake The ORX degree will more than double with each round. It's nothing at all like Shamir's ludicrously shallow strawman circuit.
2013.01.27 20:11:03, replying to "Halvar Flake (@halvarflake)": @halvarflake Diffusion is a little slower, certainly, but a few extra rounds should easily compensate for this.
2013.01.27 19:22:20: Would hardware designers prefer ORX ciphers to ARX ciphers? Can't use a Skein-type mix but can imitate Salsa20, composing a^=((b|c)<<<r).
2013.01.27 01:00:35, replying to "Nick Mathewson (@nickm_tor)": @nickm_tor But that was _fun_! When will you make a Debian package? :-)
2013.01.27 00:50:06, replying to "Justin Troutman (@justintroutman)": Proofs can be a useful guide to cryptanalysts, but it's a disaster to prioritize proofs above security as the design goal. @justintroutman
2013.01.26 22:00:11, replying to "Bert Hubert 🇺🇦 (@bert_hu_bert)": Cryptanalytic attention is by far our best hope for figuring out which crypto is secure. @PowerDNS_Bert @justintroutman @matthew_d_green
2013.01.26 20:50:26, replying to "Justin Troutman (@justintroutman)": The pursuit of such a link encourages designers to add structure. Often the same structure helps attackers! @justintroutman @matthew_d_green
2013.01.26 20:32:34, replying to "Claudio Orlandi (@claudiorlandi)": PK doesn't avoid the issue. Example: No competent cryptanalyst would recommend the Eurocrypt 2009 Hofheinz--Kiltz system. @claudiorlandi
2013.01.24 16:22:07: Some evidence that "provable security" is negatively correlated with actual security: http://cr.yp.to/talks/2013.01.23/slides.pdf
2013.01.18 20:15:24, replying to "Martin R. Albrecht (@martinralbrecht)": @martinralbrecht @hyperelliptic Looks like snow delay, so money will be hard to get. But they still have to give you written notice etc.
2013.01.18 20:02:49, replying to "Martin R. Albrecht (@martinralbrecht)": @martinralbrecht @hyperelliptic Law requires: written notice of your rights; proper food; hotel w/transport; calls; and, sometimes, money.
2013.01.18 19:49:29, replying to "Martin R. Albrecht (@martinralbrecht)": @martinralbrecht @hyperelliptic ... and did they proactively give you a written notice of your rights, and 250 EUR for the cancellation?
2013.01.18 19:45:49, replying to "Martin R. Albrecht (@martinralbrecht)": @martinralbrecht @hyperelliptic Bummer. What happened to the flight?
2013.01.18 11:40:51, replying to "Matthew Green (@matthew_d_green)": @matthew_d_green Users encrypting more than 2^70 bits need to consult the official documentation. :-)
2013.01.18 11:36:43, replying to unknown: @stouset NaCl shares API with the SUPERCOP benchmarking framework; most of the new NaCl components are appearing in SUPERCOP first.
2013.01.17 11:30:40, replying to "Matthew Green (@matthew_d_green)": @matthew_d_green There's a 64-bit block counter, with 512 bits of output per block. That's 2^70 bytes.
2013.01.17 11:29:03, replying to "Daniel Franke (@dfranke)": @dfranke Two obvious examples: (1) Lightweight: ever tried putting a cipher onto an RFID? (2) Robust: see how these users are repeating IVs?
2013.01.17 06:40:15, replying to "Daniel Franke (@dfranke)": @dfranke We still don't have secure, applicable, robust secret-key crypto. See http://competitions.cr.yp.to/disasters.html for several examples of disasters.
2013.01.16 11:02:16, replying to "CodesInChaos (@CodesInChaos)": @CodesInChaos eSTREAM ciphers are more widely used today (scrypt, VMWare View, DNSCrypt, etc.) than AES was after a similar number of years.
2013.01.16 10:17:28, replying to "CodesInChaos (@CodesInChaos)": @CodesInChaos @matthew_d_green Submissions for AES, SHA-3, etc. all started out "non standard", "less analyzed", "implemented in few libs".
2013.01.15 17:55:55, replying to "Matthew Green (@matthew_d_green)": @matthew_d_green AES + an AE mode will give you an authenticated cipher, but teaming up with a cipher designer should give better results!
2013.01.15 15:53:15: New "Competition for Authenticated Encryption: Security, Applicability, Robustness". Submissions due one year from now. http://competitions.cr.yp.to
2013.01.12 07:47:21, replying to "Ning Shang (@syncomo)": What Boneh didn't mention: if a cryptosystem _does_ fit on one slide, it's probably broken. @syncomo
2013.01.11 23:33:28, replying to "Matthew Green (@matthew_d_green)": "Random-oracle model" is a misnomer. The theorems are really just statements about generic-hash attacks. @matthew_d_green @zooko @benadida
2013.01.11 22:41:02, replying to "CodesInChaos (@CodesInChaos)": OpenSSL shouldn't be managing its own PRNG; it should be asking the OS. (In a VM the OS should ask the hypervisor.) @CodesInChaos
2013.01.11 19:11:24: Intel says that RDRAND is meant to "feed entropy directly to the register space of the running application". Huge design mistake.
2013.01.10 21:02:14: Have just listened to yet another completely unconvincing talk promoting server-supplied Javascript crypto.
2013.01.10 20:57:38, replying to "@bch@mastodon.sdf.org (@bcharder)": @bcharder @ioerror Public domain is much simpler. Is there some advantage of the BSD license?
2013.01.10 17:01:21, replying to "@bch@mastodon.sdf.org (@bcharder)": @bcharder @ioerror What exactly is the "headache"? Former anti-PD cult leader, lawyer Lawrence Rosen, admitted last year that he was wrong.
2013.01.10 05:57:24, replying to unknown: @stouset It's not safe to release the decrypted plaintext before verifying the authenticator. This is why each packet needs authentication.
2013.01.10 05:30:03, replying to unknown: @stouset Typical applications are built from crypto_box and crypto_sign, but crypto_stream is used at a lower level inside crypto_box.
2013.01.09 06:43:49: Submission deadline coming up this month for next post-quantum workshop (June in France): http://pqcrypto2013.xlim.fr/
2013.01.04 18:46:14: http://untied.cr.yp.to A few of my experiences w/ @united and its partners. Also a summary of laws that airlines don't want you to know about.
2013.01.04 06:53:33, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": @zooko No. The worst case for a properly implemented crit-bit tree is a few dozen cycles per input byte.
2013.01.04 06:50:00, replying to "You and 52 others (@bahstgwamt)": @kragen @zooko Crit-bit trees (2 control words per string) are more streamlined than PATRICIA trees (5 control words per string).
2013.01.02 06:32:25, replying to "Solar Designer (@solardiz)": @solardiz @hashbreaker @aumasson @_emboss_ n-collisions in a strong PRF size-n hash table need about n^2 queries (more with noisy queries).
2013.01.01 22:01:23, replying to "Solar Designer (@solardiz)": @solardiz @aumasson @_emboss_ Sure. The safe key lifetime depends on how many hash collisions are tolerable and how quickly collisions leak.
2013.01.01 21:56:48, replying to "Tonimir Kisasondi (@kisasondi)": @kisasondi The PDF-producing script has too many rough edges: e.g., it needs overlay indicators as specials in the DVI input.
2013.01.01 15:29:34, replying to "Tonimir Kisasondi (@kisasondi)": @kisasondi Originally, two physical transparency projectors; then many adjacent xdvi windows on a big virtual screen; now a PDF imitation...
2013.01.01 15:26:54, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": If you're not tied to hash tables then I recommend crit-bit trees. See also http://cr.yp.to/talks.html#2012.10.22 ("Data-structure lock-in"). @zooko
2013.01.01 13:03:36, replying to "Solar Designer (@solardiz)": @solardiz @aumasson @_emboss_ Yeah, we discuss this in the SipHash paper. A strong PRF reduces the damage to square root of communication.
2013.01.01 13:01:22, replying to "Tony "Abolish ICE" Arcieri 🦀🌹 (@bascule)": @bascule Temporary issue with non-PIC asm. Next version makes all the asm PIC, and includes an official Python NaCl.
2012.12.28 14:31:32: FactHacks core code snippets now online: http://facthacks.cr.yp.to
2012.12.26 09:51:49: FactHacks home: http://facthacks.cr.yp.to Code snippets coming soon. If you want Sage working from source before the talk, start compiling now!
2012.12.24 12:11:55: Patent 8218760 "invents" RSA key compression with p and q both chosen randomly from intervals. http://cr.yp.to/patents/us/8218760.html lists prior art.
2012.12.23 02:45:21: New version (including FAQ) of "Non-uniform cracks in the concrete" paper with @hyperelliptic: http://eprint.iacr.org/2012/318
2012.12.20 12:11:07, replying to "Tony "Abolish ICE" Arcieri 🦀🌹 (@bascule)": @bascule Most of the time saved is time for self-tests. Platforms vary in all sorts of nasty ways that can screw up crypto software.
2012.12.20 10:13:56, replying to "Tony "Abolish ICE" Arcieri 🦀🌹 (@bascule)": @bascule Automated testing and selection is better than manual. The name is also a problem: "C NaCl" already means the C API to NaCl.
2012.12.18 08:38:35, replying to unknown: @_not_you Huh? Why should transparent huge pages keep dirty high? Anyway, this is an ARM system that doesn't have them.
2012.12.18 05:05:22, replying to unknown: But why does the dirty block count _stay_ high? (A different workaround is putting 10 into /proc/sys/vm/*centisecs.) @_not_you
2012.12.17 06:45:24: People have been complaining for years about horrendous Linux USB slowdowns. I'm exploring one theory: "Dirty" stays high in /proc/meminfo.
2012.12.16 04:16:46, replying to "Andrew M. (@floodyberry)": @floodyberry Some analysis, unconfirmed, unoptimized: 2-block differential 80000000,84044100 has 1/500 collision chance. @aumasson @_emboss_
2012.12.15 03:13:07, replying to "Martin Boßlet (@_emboss_)": @_emboss_ Communicating n inputs 0, 00, 000, ... costs O(n^2). Storing the same inputs in a crit-bit tree costs O(n^2). What's the question?
2012.12.15 02:55:56, replying to "Martin Boßlet (@_emboss_)": @_emboss_ Another nitpick: crit-bit trees guarantee performance linear in the input size; worst case is a few dozen cycles per byte.
2012.12.15 02:51:14, replying to "Martin Boßlet (@_emboss_)": @_emboss_ Nitpick: you can't "precompute collisions for SipHash offline": yes, the output is only 64 bits, but the key is secret.
2012.12.14 18:22:06: "Crypto for 2020" in sunny Tenerife, hotel discount valid today: https://www.cosic.esat.kuleuven.be/ecrypt/cryptofor2020/ Includes "Internet crypto" research retreat: Tor etc.
2012.12.06 10:05:40, replying to "BeagleBoard.org (@beagleboardorg)": @beagleboardorg I'm looking at what seems to be pure NEON code fitting easily into the Sitara data cache and instruction cache.
2012.12.05 11:20:58: Did TI tweak the Cortex A8 CPU cores in its Sitara SoC (BeagleBone etc.)? I'm seeing some small but repeatable performance differences.
2012.12.04 07:47:30, replying to "Nick Mathewson (@nickm_tor)": No. iPhones and iPads use Curve25519; see http://www.apple.com/ipad/business/docs/iOS_Security_Oct12.pdf. iOS 4 acknowledgments already pointed to curve25519-donna. @nickm_tor @agl__
2012.11.12 08:05:27: Schedule for upcoming workshop on Cryptography for the Internet of Things: http://hyperelliptic.org/CIoT/timetable.html Incl Keccak's Bertoni, Groestl's Rechberger.
2012.11.12 07:30:36: Lysyanskaya, Tamassia, Triandopoulos, http://www.cs.brown.edu/cgc/stms/papers/authmultfull.pdf on multicast authentication: "... singing each packet individually ..."
2012.11.05 10:21:30: "Your smart heat lamps have set your marijuana plants on fire"? Cryptography-for-IoT workshop hotel deadline tomorrow. http://www.hyperelliptic.org/CIoT/
2012.10.28 21:00:36: Getting my "NIST P-256 has a cube-root ECDL algorithm" slides ready for #ecc2012. Talks will be streamed: http://ecc2012.cs.cinvestav.mx/venue.php
2012.10.22 23:05:51: Central crypto benchmarking now covers Ivy Bridge: http://bench.cr.yp.to Very few hints in Intel's manuals of where the speedups come from.
2012.10.12 04:04:46: Remote Wipe will take on a whole new meaning once the Internet of Things is connected, insecurely, to your toilet paper.
2012.10.10 15:06:23, replying to "Matthew Green (@matthew_d_green)": @matthew_d_green @hyperelliptic Most of the patent claims are limited to a specific, silly, method. The other claims have clear prior art.
2012.10.10 14:52:44: Looked more closely. The specific patented method is actually a big step backwards from 2000 Schoenmakers. @hyperelliptic @matthew_d_green
2012.10.09 23:10:12, replying to "Dmitry Chestnykh / Stop the war! (@dchest)": No! Submitting prior art to USPTO is making a gift to the patent holder. Make a web page instead. @dchest @hyperelliptic @matthew_d_green
2012.10.09 22:10:33, replying to "Tanja Lange (@hyperelliptic)": Looks like a reinvention of 2000 Schoenmakers (published 2003 Stam). 2001 Akishita and my paper are faster. @hyperelliptic @matthew_d_green
2012.10.09 19:36:38, replying to "Luciano Martins (@clucianomartins)": @clucianomartins Thanks.
2012.10.09 17:10:57: Walking around LatinCrypt wearing big nametag saying "My name is INIGO MONTOYA. You killed my paper. Prepare to die." Many confused looks.
2012.10.09 17:08:38: Has a Debian/Ubuntu upgrade quietly nuked your aircrack-ng? Check _before_ you travel. (6 hours sitting outside locked UA EZE lounge. Sigh.)
2012.09.30 04:19:50: First official SUPERCOP benchmarks are in for Curve25519 on NEON: 413346 cycles on Snapdragon S3; 8600/second on dual-core 1.782GHz APQ8060.
2012.09.29 12:36:26, replying to "Andreⓐ (@puellavulnerata)": Access to a cache line _does_ have address-dependent timing. See, e.g., http://cr.yp.to/papers.html#cachetiming sec 15. @puellavulnerata @nickm_tor @marshray
2012.09.29 12:30:38, replying to "Nick Mathewson (@nickm_tor)": Among Salsa20 users, clearly DNSCrypt has the largest mindshare at the moment, but VMWare View might have more devices. @nickm_tor @agl__
2012.09.26 12:21:02: SHA-3-over-SHA-2 advantages Schneier is ignoring: (1) higher security margin; (2) no length extensions; (3) often much better performance.
2012.09.19 08:41:07: More NEON code w/@cryptojedi now online in SUPERCOP: 459364 Cortex A8 cycles for Curve25519, side-channel protected. 1741/second at 800MHz.
2012.09.16 22:01:45, replying to "blog.plover.com (account inactive) (@mjdominus)": @mjdominus In brief: the state has sent me many threatening letters; I've threatened them with a Section 1983 lawsuit; no real action.
2012.09.16 21:27:10: I think I've spent more hours on the phone with incompetent @united agents than flying @united. (And I'm 1K.) This call: 02:32 and counting.
2012.09.15 11:30:06: Looking for experienced corporate-fraud lawyer to sue @united_airlines and @copaairlines. Know anybody?
2012.09.15 01:51:59, replying to "Tony Finch (@fanf)": BIND's "rate limiting" vs. DNSSEC DDoS attacks reminds me of anti-spam ideas from a decade ago. Hurts users; doesn't stop attackers. @fanf
2012.09.15 01:03:54: Want to help attackers kill more web sites? Install DNSSEC on your servers! #public_service_announcement
2012.09.15 01:01:12: What Vixie says: http://spamhaus.org was "injured" this week by a DDoS attack. What he doesn't say: DNSSEC massively amplified the attack.
2012.09.11 09:41:02, replying to "Matthew Green (@matthew_d_green)": @matthew_d_green @kkotowicz Compression-Related-Information Message Extraction?
2012.09.10 17:55:18, replying to "Paul Crowley (@ciphergoth)": @ciphergoth @cryptojedi It's full Salsa20/20. The ECRYPT recommendation says 12 rounds are enough but I'm more conservative.
2012.09.10 09:44:27: Cortex A8 cycles/byte, side-channel protected: AES=18.94 (OpenSSL: 25, unprotected!), Salsa20=5.47. Code w/@cryptojedi, online in SUPERCOP.
2012.09.08 12:06:08, replying to "Root Labs (@rootlabs)": @rootlabs Continuations are the start of the abuse, yes, but reexamination works even years after the patent is issued.
2012.09.07 00:10:19, replying to "Tony Finch (@fanf)": @fanf Reexamination lets the patent holder look at newer work and retroactively draft "clarifying" claims with the _original_ priority date.
2012.09.06 13:19:29: Rational behavior for patent trolls: have shills ask USPTO for "reexamination"; exploit "reexamination" procedure to add claims to patents.
2012.09.05 12:37:30: Updated scripts for readable conference name tags, simplifying insertion of your conference logo: http://nametags.cr.yp.to
2012.09.04 15:34:04, replying to "Christopher Soghoian (@csoghoian)": @csoghoian Hard to find any blameless countries. My first thought was "Canada", but the tweet was too long. :-) Anyway, what's your answer?
2012.09.04 15:22:20, replying to "Christopher Soghoian (@csoghoian)": @csoghoian UK investigative journalist sends a report to his boss. He's paid, of course. Free speech, except if UK govt runs the newspaper?
2012.09.04 14:55:35, replying to "Christopher Soghoian (@csoghoian)": @csoghoian Clarify, please. Are you saying that freedom of speech disappears when the author receives money? Or when the speech is private?
2012.09.04 14:40:17, replying to "Christopher Soghoian (@csoghoian)": @csoghoian Clarify. No freedom of speech for authors who receive royalties? No freedom of press for the New York Times? "Selling", right?
2012.08.31 22:43:17: #united_airlines sells us an expensive ticket with two upgrades. Two weeks later it says we have to pay more money for the upgrades. #fraud
2012.08.27 00:57:34, replying to "Paulo Barreto (@pbarreto)": @pbarreto @matthew_d_green Make sure to join the applied-cryptographers-at-crypto mailing list!
2012.08.26 04:41:39, replying to "Bill Ricker (@n1vux@mastodon.radio) (@n1vux)": @n1vux The general group configuration says English. Maybe Google thought you were connecting from Spain/Mexico/etc.?
2012.08.26 00:57:25: New mailing list on fixes to "Mining your ps and qs" and "Ron was wrong, Whit is right": randomness-generation+subscribe@googlegroups.com
2012.08.24 23:40:12, replying to "Carter T Schonwald (@cartazio)": @cartazio @b6n It was a big group effort. I made a few suggestions here and there.
2012.08.23 02:29:40: "The end of crypto" rump-session video is online (and should also credit Joppe Bos and Faith Chaza): http://www.youtube.com/watch?v=fErHcYXvK08
2012.08.23 02:15:18: http://crypto.2012.rump.cr.yp.to/index.html now has all of the public rump-session slides. Videos will take longer. #crypto2012
2012.08.21 21:14:58, replying to "Jacob Appelbaum (@ioerror)": @ioerror Reduce response sizes. Increase request sizes (e.g., by zero-padding). Work on phasing out support for small requests.
2012.08.21 20:58:40: DNSSEC amplifies DDoS by 51x. Kiss your site goodbye. Kaminsky: "That's fine!" Why? "Because something else amplfiies DDoS by 10x." Logic?
2012.08.21 20:12:44: #crypto2012 rump-session program now online. Will be broadcast live. http://crypto.2012.rump.cr.yp.to/index.html
2012.08.15 21:49:05: Is it just me, or is Skype becoming more and more flaky every month? Not seeing people online, losing track of chats, dropping calls, etc.
2012.08.13 19:34:54: How to build a program that computes, in 2^60 operations, DLs on a secure 160-bit elliptic curve: http://eprint.iacr.org/2012/458 with @hyperelliptic
2012.08.03 17:21:47: Morse Watchmans KeyWatcher: 4-digit user ID, 4-digit PIN, with different error messages for invalid IDs and PINs. Sigh.
2012.07.21 21:41:54, replying to "chort ↙️↙️↙️ Abolish DHS (@chort0)": http://cr.yp.to/talks/2012.06.04/slides.pdf analyzes DNSSEC security, and includes a sustained 51x DNSSEC traffic-amplification experiment. @chort0
2012.07.21 20:19:38, replying to "David Ulevitch 🇺🇸 (@davidu)": 25 queries/second (ISC-suggested "rate limit"), from 2000 DNSSEC servers, usually >1KB responses, hits victim with 400Mbps. Splat. @davidu
2012.07.21 19:41:35, replying to "Paul Wouters (@letoams)": DNSSEC is the worst DDoS amplifier on the Internet. Rate-limiting ANY queries (which are standard, btw) won't fix this problem. @letoams
2012.07.21 00:26:16: For people asking how to subscribe without a Google account: send mail to applied-cryptographers-at-crypto+subscribe@googlegroups.com
2012.07.18 03:32:28: Mailing list for applied cryptographers at Crypto: https://groups.google.com/group/applied-cryptographers-at-crypto First post: randomness BoF Wednesday after the "Public keys" talk?
2012.06.30 10:20:10, replying to "Paulo Barreto (@pbarreto)": @pbarreto @cryptopathe Hardware leakage (e.g., power consumption) is tricky. NaCl eliminates software leakage (cache, branch unit, etc.).
2012.06.29 17:58:56, replying to "Paulo Barreto (@pbarreto)": @pbarreto @cryptopathe Your CPU _will_ spill its secrets to a physical attacker torturing it with electrical probes, heat guns, and lasers.
2012.06.19 15:41:55: Interested in the future of secret-key cryptography? DIAC workshop in Stockholm, register today: http://hyperelliptic.org/DIAC
2012.06.09 13:10:15, replying to "Stefano Zanero (@raistolo)": @raistolo Gutmann spends several pages strenuously claiming that weak crypto (anything above "homebrew crypto") is not a security problem.
2012.06.09 00:41:00, replying to "Stefano Zanero (@raistolo)": @raistolo Malware exploits flaws in widely deployed crypto---but you're still not convinced that crypto is one of the things to worry about?
2012.06.08 17:36:07: Peter Gutmann, Engineering Security, 2012: "In practice cryptography is bypassed and not attacked." #flame #md5 #makingfoolofyourself
2012.06.07 02:08:53: OK, working on AppliedCrypto 2012 program. 19-23 Aug, UCSB. Need (1) volunteers to run events and (2) expressions of interest in the events.
2012.06.05 21:32:48, replying to "Matthew Green (@matthew_d_green)": @matthew_d_green @hyperelliptic @mtibouchi Do we have critical mass of Crypto attendees who plan to skip most of the Crypto talks?
2012.06.04 22:40:51, replying to "Matthew Green (@matthew_d_green)": The real Crypto program: the rump session! Plus the sunshine, the dorms, the strawberries, the late-night chats. @matthew_d_green @mtibouchi
2012.06.04 22:31:29: Non-uniform cracks in the concrete http://cr.yp.to/papers.html#nonuniform w/ @hyperelliptic: the usual security definitions in crypto are fundamentally flawed
2012.06.04 20:04:15: When DNSSEC signs a (name,IP) pair, why do people say "DNSSEC-signed name" and not "DNSSEC-signed IP address"? #securitymarketingstunts
2012.04.26 00:39:37, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": @zooko Some authenticated ciphers advertise the flexibility to use short low-security authenticators; maybe you want the 0-bit extreme.
2012.04.25 20:00:16, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": We're hoping for in-depth discussion of use cases at DIAC. The call for papers explicitly includes white papers. @zooko
2012.04.21 22:20:16: Alfred Menezes talk drew sustained applause from Eurocrypt audience. No updates from Jon "many researchers are justifiably concerned" Katz.
2012.04.21 20:23:21: UA knocks feet off bag. AMS agents falsely claim UA not liable. Can UA explain why? Email from UA: "I am unable to answer that question."
2012.04.21 20:17:31: Aha, UA admits it: "United would be held liable for damages to your baggage during international travel."
2012.04.14 10:10:36, replying to "Samuel Neves (@sevenps)": @sevenps @zooko @aumasson Linux now uses two incompatible little-endian ARM ABIs: soft-float and hard-float. You have to compile for both.
2012.04.09 12:18:49, replying to "Nick Mathewson (@nickm_tor)": @nickm_tor Similar example: THREE SPORT EXCELLENCE BONDS really made me wonder until I read the rest of the headline: TIMES AWARD WINNERS
2012.03.26 19:40:56: UA knocks feet off intl checked bags? Agents refuse to take damage report? Write to UA within 7 days; Montreal convention says UA must pay.
2012.03.25 05:03:44, replying to "Jacob Appelbaum (@ioerror)": @ioerror @zooko @agl__ Are you sure they're being stupid? Are you sure they aren't having SSL speed problems? (Why doesn't Google use 2048?)
2012.03.25 04:53:08: Accelerated scientific progress comes from improved conference interaction, which comes from larger name-tag fonts. http://nametags.cr.yp.to
2012.03.24 14:54:28: NIST asks for IETF-style hums from SHA-3 conference audience, minus finalist teams. Top: Keccak, then BLAKE. Deafening silence: Skein. Ouch.
2012.03.21 15:42:34: Cortex A8 (iPad 1) crypto: 1Gbps for high-security authenticated encryption; >1000 high-security public-key ops/second. http://cr.yp.to/highspeed/neoncrypto-20120320.pdf
2012.02.29 03:11:59, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": @zooko @agl__ If SSL isn't expensive, why does https://sourceforge.net/develop go out of its way to switch to HTTP? https://sourceforge.net/account works fine.
2012.02.24 03:47:19: SHARCS 2012: GPUs, FPGAs, ASICs, MD5, SHA-1, Grain, AES, ECDL, XL, password cracking, NSA, World War II, and more. Registration open now.
2012.02.23 05:12:20, replying to "@rpw@chaos.social — Ralf (aka RPW) (@esizkur)": @esizkur Bought two from NewEgg, two from Provantage. Already sent one directly to Corsair; they sent a replacement, which I haven't tested.
2012.02.22 08:35:07: I've now seen four Corsair Flash Voyager 64GB USB sticks fail horribly on four machines. Other USB sticks work fine. Is it just me?
2012.02.19 03:25:56: Lenstra suggests censorship of algorithms: "We hope that people who know how to do the computation quickly will show good judgment."
2012.02.11 04:14:45, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": @zooko You need better eyeballs. :-) Those graphs compare implementations of one primitive; they don't compare primitives. Read the tables.
2012.02.11 03:46:54, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": @zooko @aumasson But people who say that tree modes can't help for single cores are drawing bogus conclusions from naive performance models.
2012.02.11 03:43:38, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": @zooko @aumasson All implementations of all cryptographic primitives in the SUPERCOP benchmarking suite are single-core (and single-thread).
2012.02.11 02:49:10: 17-18 March, DC, SHARCS (Special-Purpose Hardware for Attacking Cryptographic Systems) hotel information now available: http://2012.sharcs.org/travel.html
2012.02.08 15:06:24, replying to "Paulo Barreto (@pbarreto)": @pbarreto @aumasson Are you saying that brute force isn't an attack? Or that improved brute force (if new etc.) isn't an improved attack?
2012.01.20 12:05:45: Monday deadline for 3-page submissions: "Special-Purpose Hardware for Attacking Cryptographic Systems" workshop in DC. http://2012.sharcs.org
2012.01.04 11:29:11, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": @zooko Maybe this sheds some light on your BLAKE/Skein question: "Optimization failures in SHA-3 software" http://cr.yp.to/hash/sha3opt-20120104.pdf #sha3
2012.01.04 05:09:02: Encrypted Ubuntu on the MacBook Air: http://cr.yp.to/hardware/air.html
2011.12.31 03:47:42, replying to "(@PaulM)": @paulrmcmillan Sure, feel free to post or send email.
2011.12.30 15:24:48, replying to "Jason Miller (@Aidenn0)": @Aidenn0 No. Crit-bit trees keep many top layers in cache, and standard "clustering" tricks make the bottom layers cache-friendly too.
2011.12.29 11:38:58, replying to "Alexander Klink (@alech)": @alech Most hash-randomization methods are bogus. The most sophisticated code I've seen isn't bogus but is still broken by a timing attack.
2011.12.28 17:59:11: The ultimate solution to #hashflooding: language/library designers should switch to crit-bit trees. http://cr.yp.to/critbit.html
2011.12.28 17:56:20: The first dnscache release in 1999 fixed #hashflooding by limiting itself to 100 hash probes. But this is suitable only for caches.
2011.12.28 17:54:55: Don't believe people who claim that you can stop #hashflooding by changing, or randomizing, your hash function.
2011.12.22 23:47:03: SHARCS 2012: Special-Purpose Hardware for Attacking Cryptographic Systems. Washington, mid-March, right before FSE. http://2012.sharcs.org
2011.12.09 14:50:41, replying to "Matthew Green (@matthew_d_green)": @matthew_d_green A moment ago you had "so much confidence" in Jennifer Aniston being "wrong"; now you say you'd sleep with her. Interesting.
2011.12.09 14:44:01, replying to "Matthew Green (@matthew_d_green)": @matthew_d_green Are you saying that when you review crypto software using AES you _don't_ find security problems? Serpent bad, AES good?
2011.12.09 14:29:23, replying to "JP Aumasson (@veorq)": @aumasson @matthew_d_green @cryptopathe The reality is that many standards are less secure, often much less secure, than some non-standards.
2011.12.09 14:25:59, replying to "JP Aumasson (@veorq)": @aumasson Another common argument for "don't use anything non-standard" is "standardization implies security"---another wild exaggeration.
2011.12.09 14:24:55, replying to "JP Aumasson (@veorq)": @aumasson One common argument for "don't use anything non-standard" is "all non-standards are insecure"---but that's a wild exaggeration.
2011.12.09 14:16:54, replying to "JP Aumasson (@veorq)": @aumasson There's very little evidence for this Pr inequality. Anyway, @matthew_d_green seems to be claiming something much more extreme.
2011.12.09 11:28:49, replying to "Matthew Green (@matthew_d_green)": @matthew_d_green Seriously? Whenever you see non-standard crypto, you confidently say it's bad? You claim that Serpent is bad, for example?
2011.12.08 12:41:30, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": @zooko @sevenps @aumasson Tegra update: Skein down to 37.62 cpb. But most of the ARM implementations still aren't Cortex-optimized asm.
2011.12.06 18:35:18, replying to "Georg (@ochsff)": @ochsff Announced http://www.cace-project.eu/index.php?Itemid=12&id=4&option=com_content&task=view early 2008. Heard much later about Google's lower-security NaCl; decided no real risk of confusion.
2011.12.06 16:59:13, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": @zooko @cryptopathe "Plaintext-Recovery Attacks Against Datagram TLS" seen on http://www.isoc.org/isoc/conferences/ndss/12/program.shtml. Standard, yes; secure, no.
2011.12.05 23:06:09, replying to "Joachim Strömbergson (@Kryptoblog)": @Kryptoblog @cryptopathe 1996: Top cryptanalysts recommend scrapping MD5. 1996-2004: MD5 standardization blithely ignores the cryptanalysts.
2011.12.05 15:50:12, replying to "(@aleks___0)": @sasha_crypto You think that papers like "The RC6 block cipher" are evidence of AES scrutiny (and thus AES security)? Your metric is busted.
2011.12.05 14:00:18, replying to "Pascal Junod (@cryptopathe)": @cryptopathe Presumably you then have 1000 security disasters, half using standard crypto and half not. You think this is a new experiment?
2011.12.05 13:44:24, replying to "Pascal Junod (@cryptopathe)": @cryptopathe Let's try an example: the new DTLS security disaster in both OpenSSL and GnuTLS. Do you recommend using DTLS? It's a standard!
2011.12.04 13:04:49, replying to "Pascal Junod (@cryptopathe)": @cryptopathe Using standards is "good security practice"? Really? Using standard RSA-512 in 1998? Standard MD5-based certificates in 2008?
2011.12.04 12:59:24, replying to "(@aleks___0)": @sasha_crypto Way more? What's your metric? >20 different authors have written papers cryptanalyzing AES, but the same is true for Salsa20.
2011.12.04 12:22:40, replying to "zooko❤ⓩ🛡🦓🦓🦓 (@zooko)": @zooko Most smartphone CPUs have NEON, but Tegra 2 doesn't. (Tegra 3 does.) ARM implementations are trickling in now, with and without NEON.
2011.12.01 17:04:16: Our paper "The security impact of a new cryptographic library" is now online: http://cr.yp.to/highspeed/coolnacl-20111201.pdf
2011.11.21 10:29:48: Each Tegra 2 core has its own CCNT permission bit. Sigh. Maybe also true for Intel+AMD but they're smart enough to enable RDTSC by default.
2011.11.02 04:05:50: Taipei end of Nov: warm weather; cool electronics; defending Internet crypto against quantum computers. Reg still open. http://pq.crypto.tw
2011.10.29 13:00:39: SO pre-orders asian vegetarian. UA gives her: chicken. Complain? Pasta. UA arrival snack: rotten salad. Complain? Ham sandwich. #unitedsucks
2011.10.22 17:12:51: Indocrypt 2011 schedule posted and registration opened: http://2011.indocrypt.org
2011.10.19 19:56:43: Would Delta really have called the RDU cops? A small travel story http://cr.yp.to/conferences/rdu.html
2011.10.02 13:28:07: NaCl's build process automatically tries all implementations and gcc options and selects the fastest. Why? Example: http://zombe.es/post/4059999783/openssl-outmoded-asm
2011.08.17 22:01:05: Slides from last night's "holy shit, did they just announce an attack on full AES?" Crypto 2011 rump session are now at http://rump2011.cr.yp.to
2011.07.17 10:06:38: Indocrypt 2011 submission server is open: http://2011.indocrypt.org/submissions.html. Abstract deadline 31 July, revision deadline 7 August.
2011.07.07 18:21:10: Worried about collisions in your favorite hash function? Try a collision-resilient (and super-fast) signature system: http://ed25519.cr.yp.to
2011.07.04 16:57:19: Indocrypt 2011 invited speakers announced: Anderson+Paar+Rescorla+tutorials: Dingledine+Lange. (Sanjit Chatterjee and I are program chairs.)
2009.10.04 13:36:54: The FSB attack team successfully found collisions in the FSB48 compression function: http://eprint.iacr.org/2009/292
2009.07.24 18:06:43: NIST has announced second-round SHA-3 candidates: http://bit.ly/QEFXp
2009.07.23 06:11:44, replying to "Engine Yard (@engineyard)": @engineyard code posted at http://cr.yp.to/nearsha.html
2009.07.22 19:40:09, replying to "Stan Seibert (@seibert)": @seibert congratulations!
2009.07.22 18:06:59, replying to "Engine Yard (@engineyard)": @engineyard If codingcrypto has first place and i'm tied with seibert for second then i'm withdrawing; please skip the lottery. thanks!
2009.07.22 17:46:02, replying to "Engine Yard (@engineyard)": @engineyard If the public 30(codingcrypto), 31(seibert), 31(seibert), 31(hashbreaker) results are correct, second place should go to seibert
2009.07.22 02:27:56, replying to "Stan Seibert (@seibert)": @seibert Of course, we haven't heard yet from the quiet supercomputer clusters lurking in the background until the last moment...
2009.07.22 01:50:23, replying to "Stan Seibert (@seibert)": @seibert The operators of http://jazzychad.com/engineyard/ seem to have fixed their scripts; dariencrane doesn't show up any more.
2009.07.22 01:27:09, replying to "Engine Yard (@engineyard)": @engineyard bUGs BUgs bUGS bUgS bLAnk BlAnK BlANK BLank buGS bugS bUGS bUGs dCao2
2009.07.22 01:07:57, replying to "Engine Yard (@engineyard)": @engineyard CoWS coWS CowS cOWS DiRTY DIrtY DirTy DIRtY COWS COWS cOwS cOWS bvpDq
2009.07.21 01:56:42, replying to "Engine Yard (@engineyard)": @engineyard BuGs BUGS bugs bUgs BlAnk BlanK bLaNk blaNk BUGs BUGS BUGs BuGs banzb
2009.07.20 21:26:12, replying to "Engine Yard (@engineyard)": @engineyard BuGs BUgS bugs BuGS blANK BlaNK BLAnk BLanK bUGS BuGS bugS BUGs ttue6
2009.07.20 01:43:47, replying to "Coding & Crypto (@CodingCrypto)": @CodingCrypto Greetings, CodingCrypto!
![[media]](1534310488732930048/278.png){kind=link}
![[media]](1529891717230391296/283.png){kind=link}
![[media]](1522682067267440641/279.jpg){kind=link}
![[media]](1521594940257542146/280.jpg){kind=link}
![[media]](1520836496609071104/305.jpg){kind=link}
![[media]](1494659108959506437/280.png){kind=link}
![[media]](1494571069839065088/280.jpg){kind=link}
![[media]](597375729052086272/117.jpg){kind=link}
![[media]](584953501056237568/116.jpg){kind=link}
![[media]](510552968912191489/117.jpg){kind=link}
![[media]](455762310905098240/116.jpg){kind=link}
