microblog.cr.yp.to
Open in
urlscan Pro
131.193.32.109
Public Scan
URL:
https://microblog.cr.yp.to/
Submission Tags: phishingrod
Submission: On July 29 via api from DE — Scanned from DE
Submission Tags: phishingrod
Submission: On July 29 via api from DE — Scanned from DE
Form analysis 0 forms found in the DOM
Text Content
THE CR.YP.TO MICROBLOG
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).
--------------------------------------------------------------------------------
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!
--------------------------------------------------------------------------------