Search
Items tagged with: defcon
Last year, I went to the Quantum Village and encountered some absolute bullshit, which I proceeded to call out.
This year, while I was walking around the Crypto + Privacy Village at DEFCON 31 in fursuit, a wild Cendyne approached me and asked, “There are going to be some debates at the Quantum Village; do you want to go check them out?”
I’m not going to recite a play-by-play of the events that occurred there (I’m sure it’s recorded elsewhere online already… and if not, Cendyne blogged about it too), but the gist of it was an Oxford-style debate whose outcome would determine the official position of the Quantum Village.
The first topic for our Second Annual #Quantum Village Debate:“The Quantum Village believes individual citizen privacy will be enhanced with the fielding of new quantum technologies.”
David Joseph will argue for the proposition
Troy Mills will argue against.
You will vote.
Bob Gourley, Quantum Village @ DEFCON 31
Not to throw too much shade, but this characterization is misleading for the actual content of the debate.
David Joseph certainly argued in favor of quantum technology enhancing individual citizen privacy.
However, Troy Mills’ position seemed less against and more middle of the road… which, to be fair, is the most reasonable position to take on the question. None of us have access to a crystal ball that can reveal the future for any technology with any degree of certainty. Experts can, and often will be, wrong about technology.
The absence of a real opposition meant choosing between an optimistic pie-in-the-sky windbag who stammered down their nose at a question from “the person in the… dog suit?” and someone who’s kind of 50/50 about the whole ordeal (but performatively takes the side of opposition).
Art: valery91thunder
My question, by the way, is an obvious one to ask when presented with the notion of unstealable quantum money: “How do you make unstealable money that can also be spent?”
This isn’t a one-dimensional question, either.On one paw, you have the risk of rubber-hose attacks. Just because you cannot steal quantum money with math doesn’t mean you cannot steal it with violence. If it can be spent, it can be stolen. Model your threats accordingly.
On the other, as Patrick McKenzie is fond of pointing out, our financial systems depend on an optimal amount of fraud, which is non-zero. Quantum Money, as postulated, is incompatible with modern financial systems and human error.
I am not an expert in quantum technologies. My only exposure to them is as a threat to some of the cryptography we use today.
We didn’t stick around for the vote, because we needed to leave for another event.
That night, I went on the Quantum Village discord and saw the participants there found my question insightful.
The point made about how do you spend quantum money was interesting. Quantum money has been introduced as a way of preventing counterfeiting. If you do an operation called the controlled swap between a valid “coin” and a test coin, you can reveal the validity of the coin without “measuring” the coin. The problem is that this can be put to any other area – for example you could search someone’s “quantum-safe storage” for specific key words without destroying the state.This is something that I would not have considered without seeing this debate.
QuantumNerd#0000 on the Quantum Village Discord
After discussing further with the participants in the audience, and reflecting on my experience from last year, my takeaway isn’t at all that the Quantum Village is wittingly hosting security charlatans or engaged in vapid performative theatrics.
Ultimately, I think the Quantum Village suffers from a lack of vocal skeptics involved in their planning and Call For Presentations.
With that in mind, I would like to make a few suggestions to the community at large to make the Quantum Village a better experience for DEFCON 32 in 2024.
Soatok’s Proposal
First, the Quantum Village need more cryptographers; both in attendance and as speakers.
This includes aspiring cryptographers and students. You’re likely better at discussing security threats and understanding how cryptography-relevant quantum computers will impact society than you give yourself credit for. Many of you have exactly the knowledge and experience needed to mount an honest opposition to quantum optimism.
To make the intermingling of the two villages seamless, I’d like to ask the DEFCON event staff to place the two villages next door to each other in 2024, if possible.
Whether or not that last request can be satisfied, as a stretch goal of this overall effort, I think a joint quantum/cryptography CTF would be a worthwhile endeavor; especially if we can get laboratories involved in modern cryptography validation to contribute tools for assessing side-channels.
Partly because it would be fun to see hackers defeat Quantum Key Distribution with side-channel emissions. Partly because it would be a great technical challenge for all parties.
Stretch goal for the stretch goal: Somehow involving gold atoms with the Crypto & Privacy Village’s Gold Bug challenge is a shitpost too good to pass up.
https://twitter.com/noid/status/889326941899296768
Final Thoughts
It may be tempting for some to look at my experience these past two years at the Quantum Village and use it to discredit or demean the people involved. I don’t agree with this course of action.
The most valuable thing you can do for your community is to help them. Build others up, don’t tear them down.
Yes, you still must call the charlatans out. “If you see fraud and don’t say fraud, you are a fraud,” is a Nassim Nicholas Taleb quote worth remembering.
However, well-meaning people make mistakes and are sometimes misinformed.
Everything I have observed from the Quantum Village and its attendees leads me to believe these are correctable problems, provided the right people get involved. And if you’re reading my blog, you’re probably one of the right people.
If we do not help the Quantum Village at DEFCON, I fear it will likely become a magnet for fraudsters like Terra Quantum and TimeAI that want to get their foot in the door by calling themselves a DEFCON speaker; using the unchecked optimism of the Quantum Village as a tool to manipulate. Nobody wins.
Skin–er, Fur–in the Game
For my part, at some point between now and DEFCON 32, I intend to submit a talk about cryptography and the real-world threat of quantum computers.
This is the quantum-relevant topic I feel most qualified to discuss, partly because other cryptographers have had to correct me about mistaken beliefs on the topic in the past.
If accepted, I will deliver the talk in fursuit.
If you want to get involved too, the Quantum Village’s website is the best place to start. They’re active on Discord.
https://soatok.blog/2023/08/20/defcon-quantum-village-2-electric-boogaloo/
#DEFCON #Quantum #QuantumVillage
If you follow me on Twitter, you probably already knew that I attended DEFCON 30 in Las Vegas.If you were there in person, you probably also saw this particular nerd walking around:
That’s me, wearing a partial fursuit.
The collar reads “Warning: PUNS” in a marquee.In addition to being shamelessly furry and meeting a lot of really cool hackers (including several readers of this blog!), I attended several village talks (and at least one Sky Talk).
For some of these talks, I attended in fursuit. For others, I opted instead to bring my laptop and take notes. (Doing both things is ill-advised because it’s hard to type with paws, and the risk of laptop damage from excess sweat gives me pause, so it was one or the other.)
To be terse, my DEFCON experience was overwhelmingly positive. However, one talk at the Quantum Village had an extremely sus abstract (which was pointed out to me by Cendyne), so I decided to attend in person and see for myself.
Screenshot of the talk abstract.
Unfortunately, my intuition as a security engineer did not let me down, as we’ll explore below. But first, some background information.
What is DEFCON, Exactly?
(Feel free to skip this section if you already know.)DEFCON is a hacking and security conference that takes place every year in Las Vegas, NV.
Unlike the stuffy Industry- and vendor-oriented events, DEFCON is more Community focused. Consequently, DEFCON has an inextricable counterculture element to it, and that makes it unique among security conferences.
(Some of the Security BSides events may also retain the same counterculture attitudes. However, that depends heavily on the attitudes of the local security/hacking scene. Give them a chance if you live near one, or consider starting your own.)
Put another way: DEFCON is to punk rock what USENIX is to classical. You’ll find good practitioners in both genres, and a surprising amount of overlap, but they can be appreciated independently too.
Which is why very few people balked at a group of furries running through Closing Ceremonies.
https://twitter.com/DCFurs/status/1558947697469448192
The weirdness and acceptance of DEFCON is a reflection of the diversity of the infosec community, and that’s a damn good thing.
In addition to DEFCON’s main track, there are a lot of so-called Villages that focus on different aspects of hacking, security, and the community.
For example, the Crypto & Privacy Village.
Photo: Cendyne
One of the many aspects of DEFCON is that you find yourself surrounded by people with deep expertise in many different areas (not just technological) who aren’t afraid to call you on any bullshit you spew. (Some of this fearlessness may be due to how much alcohol some people consume at the conference; I generally don’t drink alcohol, especially when fursuiting.)
Vikram Sharma’s Talk at the Quantum Village at DEFCON 30
The M.C. of the Quantum Village introduced Vikram by saying, “You should know who he is,” and saying that he’s deeply involved in policy discussions with government agencies. He was also described as a TED speaker.https://www.youtube.com/watch?v=SQB9zNWw9MA
I came to the talk intentionally unfamiliar with Vikram’s previous presentations, and with an open mind to the material he was going to share, so to avoid preconceived notions or unconscious bias as much as humanly possible.
The M.C.’s introduction primed me to expect a level of technical competence with cryptography and cryptanalysis on par with, or better than, a typical engineering manager that oversees cryptographers.
Vikram’s talk did not deliver on this built-up expectation.
Vikram Sharma’s Arguments
Vikram’s talk can be loosely distilled into a few important points:
- Cryptography-Relevant Quantum Computers are coming, and we don’t know when, but most experts believe within the next 30 years (at most).
- Although NIST has been working since 2015 on post-quantum cryptography, the advancements in cryptanalysis against Rainbow and SIKE highlight how nascent these algorithms are, and how brittle they may prove to be against mathematical advancements.
- In order to be ready to defend against Quantum Adversaries, we must adopt a mindset of “crypto agility” when engineering our applications.
- For enterprise customers, a Key Management Service that uses Quantum Key Distribution between endpoints in addition to post-quantum cryptography is likely necessary to hedge against advancements to post-quantum cryptanalysis.
The first two points are totally uncontroversial.
The third is interesting, and the fourth is a thinly-veiled sales pitch for Vikram’s company, QuintessenceLabs, rather than a serious technical argument.
Let’s explore the latter two points in more detail.
Art: LvJ
“Crypto Agility” From an Applied Cryptography Perspective
Protocols that utilize “crypto agility” are not new. SSL/TLS, SSH, and JWT all permit some degree of flexibility in the ciphersuite selection, rather than hard-coding the parameters.For earlier versions of SSL/TLS, you could encrypt with RC4 with SHA1, and that was totally permitted. Stupid, but permitted. Nowadays, we use AES-GCM or ChaCha20-Poly1305 with TLS 1.3.
The story with SSH is similar, and there’s a lot of overlap in the user experience of configuring SSL/TLS for webservers and configuring OpenSSH. Even PGP supported different ciphers and modes. Crypto agility was the norm for many years.
JSON Web Tokens (JWT) is the perfect example of what happens when you take “crypto agility” too far:
- An attacker can change the
algheader’s value tononeto allow for trivial existential forgery. This surprises users.- An attacker can take an existing token that uses an asymmetric mode (
RS256,ES256, etc.), change thealgto a symmetric mode (i.e.HS256), then use the public key (or a hash of the public key) as a symmetric key, and the verifier would just blindly accept it.When you maximize “crypto agility”, you introduce dangerous levels of in-band protocol negotiation.
Crypto Agility tends to become a security problem: When an attacker can entirely decide how the target system behaves, they can often bypass your security controls entirely.
Therefore, anyone who speaks in favor of crypto agility should be very careful about what, precisely, they’re advocating for.
Vikram’s talk wasn’t clear about these nuances. At the opening of the Q&A session, I asked the following question:
How do you balance your proposal for crypto agility with the risks of in-band protocol negotiation?
He declined to answer this question directly. Instead, he directed me to email his CTO, John Leiseboer, adding, “He would be better able to speak to that.”
Art: LvJ
So I returned to my DEFCON hotel room and sent an email to the email address that was displayed on Vikram’s slideshow.
Soatok’s First Email to QuintessenceLabs
This was mostly an attempt to be diplomatic so as to not scare them off from responding:Hi,I attended your CEO’s talk at the Quantum Village at DEFCON 30. I was very interested in the subject, and Vikram’s delivery of the material was appropriate for the general audience. I did have one question, but he suggested that would be better answered by your CTO.
For a bit of background: I work in applied cryptography.
My question is, “How do you balance your proposal for crypto agility with the risks of in-band protocol negotiation?”
To add color to this question, consider the widely exploited standard, JSON Web Tokens. To change the cryptographic properties of a JWT, you only need to change the “alg” header. This is maximally agile.
Unfortunately, you can specify “none” as an algorithm. This surprises users: https://www.howmanydayssinceajwtalgnonevuln.com/
Additionally, an attacker can take a token signed with an asymmetric key (e.g. RSA), change the alg header to HMAC, and then use [a hash of] the asymmetric public key as if it were a symmetric HMAC key, and achieve trivial existential forgery.
The same concerns, I feel, will crop up when migrating to a hybrid post-quantum design. Cross-protocol interactions of the incorrect secret keys would, from by understanding of Vikram’s talk, be made possible if an attacker can mutate the metadata table.
There is a way out of this mess: Versioned Protocols. Using JWT as an example, a contrary proposal that can support cipher agility but only for ciphers (and constructions of ciphers) that cryptographers have approved is called PASETO. https://paseto.io
If a vulnerability in the current supported protocols (v3, v4) is discovered, the cryptographers behind PASETO will specify new modes (e.g. v5 and v6). Currently the only reason they’re considering any such migration is for hybrid post-quantum signatures (P384 + Dilithium, Ed25519 + Dilithium).
I think the general idea of crypto agility is the right direction for addressing the risk of cryptography relevant quantum computers, but I would caution against recreating the protocol foot-guns made possible by the wrong sort of agility.
Vikram suggested you would be able to speak more to how your designs take these threats into consideration. I’m very interested in this space and would love to learn more about how your designs work at a deeper level.
Thank you for your time,
Soatok
(Typos included in original email)
I didn’t hear back from them for several days, so I hunted down the CTO’s email address directly (thanks, old mailing list discussions!).He quickly responded with this:
John Leiseboer’s First Response Email
Hi Soatok,My apologies for not responding sooner. I’ve been travelling and in meetings across three time zones. It’s been difficult to find time to absorb your questions and put together a response.
Please give me a few more days to find some time to get back to you.
Regards,
John
I want to pause here and make something very clear: My actual question is the most basic and obvious question any credible security engineer that works with cryptography would ask in response to Vikram’s presentation.
Art: Swizz
If you were to claim, “Everyone should use crypto agility,” and don’t qualify that statement with nuance or context, then a follow-up question about the risks of crypto agility is inevitable.
If this question somehow doesn’t come up, you’re in the wrong room of the wrong security engineers when you rehearse your pitch.
Why, then, would the speaker not be prepared for such a question? Isn’t he routinely offering similar talks to policy experts for government agencies?
Why, also, would his company’s CTO not be able to readily answer the question without needing additional time to “absorb” this question and put together a response?
It’s not like I asked them to provide a machine-verifiable, formal proof of correctness for their proposals.
I only asked the most basic Cryptography Protocol Design 101 question in response to their assertion that “crypto agility” is something that “companies” should adopt.
The proof, the proof, the proof is invalid!We don’t need no lemma–Proof by contradiction fail!
Fail, contradiction, fail!
With apologies to Rock Master Scott & The Dynamic Three
Was this company’s leadership blind-sided by the most basic question of the field of study they’re hoping to, at least in part, replace?Did they fail to consider an attacker that alters the metadata associated with their encrypted data in order to convince the “agile” cryptosystems to misbehave?
I will update this post when I have an answer to these very interesting questions.
(Update) QuintessenceLabs Responds
This is one email, but I’m going to add my commentary between paragraph breaks.Hello again Soatok,I’ve just read your blog where you criticised Vikram’s DEFCON talk. I was disappointed that you couldn’t wait for me to get back to you with the more detailed response that I promised to provide you last night.
Mea culpa. If I don’t press “publish” when the iron is hot, these posts stay in rough draft hell for 12-15 months, and I wanted to get my feedback (and the necessary context for said feedback) to the Quantum Village.The short answer to your question, “How do you balance your proposal for crypto agility with the risks of in-band protocol negotiation?”, is simply that our proposal does not permit in-band negotiation. I suppose I could have provided you with that simple answer, but I expected that you’d want more than that. And I certainly wanted to provide you more. So, with apologies to Winston Churchill, if I had more time I would have written a shorter response.The problem with the term “crypto agility” is that it means different things to different people. In your case, you talk about the “crypto agility” of SSL/TLS, SSH and JWT. The problem, as you are aware, and point out in your email and blog, is that crypto agility, as implemented in these protocols, introduces security issues. At QuintessenceLabs we are well aware of the issues arising from the sort of crypto agility that provides too much flexibility to users (and attackers are a class of user as far as I’m concerned), and fails to account for imaginative use of the agile features.
Although I do not yet have access to Vikram’s slides, I will point out that the specific example used during the talk included encrypted credit card numbers and a separate metadata table that stored the algorithms used to encrypt said credit card numbers.(He specifically spoke to upgrading from AES-128 to Kyber; which I thought was an odd proposition considering Kyber is a KEM not a symmetric cipher, but I dismissed that as misspeaking.)
Vikram’s metadata table proposal necessarily implies some kind of in-band negotiation, which is the bad type of crypto agility.
The following is taken from the introduction of an internal QuintessenceLabs Technical Note:“The term “cryptographic agility” is defined within QuintessenceLabs as a key management capability that permits the coding of software applications without the application code needing to specify or refer to specific cryptographic algorithms, key lengths, modes of operation, or similar cryptographic details. This capability enables applications to migrate between key types and cryptographic algorithms without a need to update the application software.
Specification of key types, strengths, modes, and cryptographic algorithms, etc. is the responsibility of a key management administrator. The key management platform delivers key material and meta data to applications in such a way that the cryptographic service or library used by the application can perform cryptographic operations in accordance with the attributes attached to the key material.”
This would have been very useful to include in the DEFCON talk. (It would have also been helpful if the speaker was prepared to answer such questions about the proposal!)I generally think developers shouldn’t even need to care about the ciphers and algorithms being used; only that they’re secure, fast, and appropriate for their security goals. i.e. While AES-256-GCM might be okay for many use cases, it’s not how you should be storing users’ passwords.
In this regard, it sounds like the actual proposal is closer to NaCl/libsodium’s
crypto_box()API, except the underlying library can tolerate algorithm upgrades (e.g. from X25519 + Xsalsa20poly1305 to something like X25519/Kyber768 + XChaCha20 + BLAKE2b-MAC). Which is totally reasonable.This is very similar to what I did with my open source cryptography library, after all. It wraps libsodium, and if I decided to upgrade it to be post-quantum secure, I could do so without my users noticing (except maybe some bandwidth and performance differences).
The simplest way to tolerate such upgrades, by the by, is to use some sort of versioning scheme (which is the non-agile crypto design), which is what I’ve been proposing all along.
Some key points to note about our implementation:
- The application developer has absolutely no control over which algorithms, key lengths, modes of operation or other crypto-related attributes are used.
- The cryptographic key is actually a “managed object”. It is a protected object that encapsulates the key values and attributes that define how the key is to be used, including attributes such as cryptographic algorithm, key length, mode of operation, permitted uses (e.g. encrypt, decrypt, sign, signature verify, MAC, wrap, unwrap, etc.), links to related managed objects (e.g. a private key has an attribute that is it’s associated public key identifier), not-before and not-after time stamps, and maximum usage limits after which the key must be retired for use for protect operations.
- The cryptographic subsystem (whether that is an HSM, smart card, library, external service, …) presents a very simple API. Again from our internal Technical Note (was this in Vikram’s presentation?):
This is actually reasonable! Per Sophie Schmieg:https://twitter.com/SchmiegSophie/status/1264567198091079681
“The application code is responsible for the business logic of the application. The application code makes no low level and direct cryptographic calls. Instead, it makes calls that abstract away the cryptographic details.An example of how this may work is as follows:
protected_data = protect(sensitive_data, policy);In this example the sensitive data is the data to be protected, the policy indicates what type of data, or type of protection is required, and the result returned is the protected data. More specifically, the policy could be a template name such as “CCN-Policy”, which might be used for protecting credit card numbers.”
I’m not sure I like this API (protectis way too vague), but the intent is much clearer than some vague notion of “crypto agility”.The application is responsible for understanding the type of information it is working with. It needs to know whether it’s handling sensitive data or not. It needs to know whether sensitive data needs to be protected. It needs to know the classification of, or how to classify, the data. I think that’s reasonable, after all the application is implementing the business logic.
Why not simply encrypt everything by default and let developers specifically opt out for data classified as not sensitive?Then if a developer adds a field down the road and somehow forgets to classify it, the database administrator only ever sees ciphertext.
So as the pseudo code above illustrates, the application passes the sensitive data and the classification (encoded in the ‘policy’ attribute) to the cryptographic subsystem to figure out what to do cryptographically.
If you can avoid developers having to even care about these details, while still getting the details right, that’s a win.
- The policy that defines the cryptographic attributes is separately managed. In the case of QuintessenceLabs’ products, this is the responsibility of a key management administrator, or a security officer, who has a cryptographic policy management role.
- The returned, protected data is an object, or structure that encapsulates not only the result of the cryptographic operation, but attributes that allow the inverse operation (“unprotect”) to be performed by the crypto subsystem.
This is actually not clownshoes. Thankfully.
- The policy can be changed at any time. This the agile part of the implementation. Today the policy says use AES-128-CBC, tomorrow is says use AES-256-GCM.
So, a couple of things about this specific example.
- AES-128-CBC is vulnerable to padding oracle attacks.
- If you support both AES-CBC and AES-GCM in the same code path, you can use the legacy CBC mode support to trigger a padding oracle attack to decrypt GCM ciphertexts.
Isn’t cryptography fun?
Art: Swizz
Adaptive attacks aside, cryptography migrations are way more challenging that your technical description implies. You’re going to have to do the following, in this specific order.
- Make sure your entire fleet can decrypt messages AES-GCM ciphertexts before any machine writes any data using AES-GCM.
- Only after step 1 is complete, you can upgrade your fleet to start writing records with AES-GCM.
- Re-encrypt all old records to use AES-GCM instead of AES-CBC.
- Turn off support for the legacy CBC mode.
If you attempt to move onto step 2 before step 1 is finished, you will find your network in a split-brain scenario where freshly-encrypted data cannot be read by some machines.
If you attempt to move onto step 3 before step 2 is finished, you will find some machines are still writing the legacy format.
If you attempt to move onto step 4 before step 3 is finished, you will lose access to some subset of old encrypted data.
Art: LvJ
It’s simply not possible to design a “crypto agile” application at any significant scale that totally avoids any window of downgrade susceptibility without also losing access to old encrypted data.
Until your entire network has reached step 4, you’re necessarily going to be vulnerable to in-band negotiation.
Also if you’re using the same key for multiple records (or the same wrapping key for multiple data keys), you’re going to read up on symmetric wear-out and the birthday paradox.
HKDF helps, but it has a specific way it needs to be used in security proofs.
Obviously as new algorithms are introduced, the crypto subsystem will need to be upgraded. But the application should not have to be changed.Please feel free to ask more questions. But please be patient. Right now I’m sitting at the check-in gate at Dulles Airport using a laptop with a battery rapidly running down. For the next 30 or so hours I’ll be flying back home to Australia. I’m always happy to receive questions. I would ask though that you have some respect for my time and give me a chance to catch my wind before you publish an article without allowing me the time to respond properly.
The technical details that were absent from the DEFCON talk I watched, which only cryptographers and security engineers will really care about, were essential and should have been included.I still disagree about the properties of their proposed “crypto agility” in practice (especially at cloud scale, which seems to be where QuintessenceLabs’ CEO wants to operate), but at least this is a much more reasonable proposal.
(The remainder of this blog post remains unchanged from what was written before John’s reply was edited in.)
Against Quantum Key Distribution
While the response to my question about “crypto agility” was disappointing, their argument for Quantum Key Distribution is just weird.Quantum Key Distribution (QKD) doesn’t scale well enough to protect consumers.
Suppose you’re accessing a brand new computer and want to login to your bank’s website to check your account balance. In this scenario, QKD is useless for you: You haven’t established a secure channel via quantum entanglement yet. You probably don’t even have the hardware or optic channel necessary to do so.
QuintessenceLabs doesn’t acknowledge this scaling issue explicitly in their Quantum Village slides. Instead, they pitch QKD as a solution for businesses (rather than users) that want to add a layer of quantum security to their Key Management Services (described vaguely as “interacting with HSMs”).
I’m not sure who exactly their intended audience is with this sales pitch: Are they trying to sell this to, or compete with, large cloud providers?
Art: LvJ
Either way, this isn’t the sort of thing that resonates well with most hackers (who are more aligned with protecting users than protecting companies), so DEFCON isn’t really the best venue for such a sales pitch.
To their credit, they don’t entirely handwave post-quantum cryptography as a solution to cryptography relevant quantum computers. Instead, they claim that QKD is an “optional” way to protect communications when post-quantum cryptography is broken. Vikram comes short of describing these algorithmic breaks as “inevitable” in his presentation.
Here’s the rub: QKD isn’t magic.
Just as the correct response to, “What’s your threat model?” isn’t, “Well why don’t you try to disprove Heisenberg? Checkmate atheists!” the solution to quantum computing isn’t to throw all of discrete mathematics out with the bathwater in favor of relying only on quantum entanglement.
Even if you assume that the physical properties being leveraged to secure QKD cannot be directly defeated, you still have to deal with side-channel attacks. Et cetera.
That’s not to say that QKD research isn’t valuable or interesting. But I would strongly caution anyone who’s considering deploying it in production to talk to cryptographers and other security experts first.
We’re here to help!
Art: HarubakiBurning Trust at DEFCON 30
DEFCON isn’t at all a vendor expo like Black Hat USA where you send sales drones to hock blinkenboxen that claim to secure networks.DEFCON is where serious researchers and eccentric geeks exchange 0days for cocktails and solve interesting technical challenges.
https://twitter.com/telechallenge/status/1558891761610723330
My point is: If you present bullshit at DEFCON, you will be called out on it.
When I sat down at the Quantum Village to watch Vikram’s presentation, I honestly wanted it to not be bullshit.
After all, a lot of talented hackers lack refinement in public speaking, especially with talk abstracts. Conversely, a lot of business people (i.e. the CEO of a company) might be so accustomed to writing abstracts for a different audience, even if they ultimately deliver a hacker-focused talk in the end.
Therefore, in my mind, it’s possible that the content of the talk would be surprisingly excellent. Unfortunately, I left disappointed.
I can’t help but wonder if Vikram’s company being one of the four sponsors for the nascent Quantum Village prevented the necessary bullshit filter from being utilized to screen his talk.
He, and his employees, might rightfully claim to be experts on quantum technology, but they certainly don’t understand cryptography as well as they like to believe.
The thought of a sponsor bypassing the bullshit filter certainly makes me a little distrustful of the Quantum Village going into DEFCON 31.
Recommendation for DEFCON 31 and Beyond
The Quantum Village should reach out to the Crypto & Privacy Village to help review any talks that involve cryptography, moving forward.This will help in two ways:
- Cryptography and privacy experts will be involved in the process.
- Someone who doesn’t have a perverse incentive will likely be involved in the process, which makes it easier to tell a sponsor, “Hell no.”
A particularly motivated bullshit artist with sufficient capital might simply sponsor both villages, so it’s not 100% foolproof, but you can always count on weirdos in fursuits like me to be the last line of defense, should all else fail.
Update:
https://twitter.com/FiloSottile/status/1560165504312135680
I stand corrected. This attack vector won’t work. Thanks, Filippo!
Closing Thoughts
I was originally going to delay publishing this until QuintessenceLabs had a chance to respond to my question, or at least until all of the slide decks were published (so I could cite them carefully in my critique), but I honestly wanted to get my recommendation off my chest and in the hands of the Quantum Village organizers before I get distracted by the work that piled up while I was at DEFCON.I might blog for free, but that doesn’t mean I don’t have a job to do, or bills to pay.
If you (or someone you work for) were sold on “crypto agility”, consider versioned protocols instead. And if you’re going to invest in custom hardware, take a page out of Nintendo’s book: simply burn fuses with each new protocol version to prevent downgrade attacks.
You probably don’t need quantum encryption to solve any of the problems you face in the immediate future.
https://soatok.blog/2022/08/18/burning-trust-at-the-quantum-village-at-defcon-30/
#cryptographicProtocols #cryptography #DEFCON #inBandNegotiation #JWT #postQuantumCryptography #QKD #QuantumEncryption #QuantumKeyDistribution #QuantumVillage #QuintessenceLabs #QuintessenceLabs #securityEngineering #VikramSharma
If you follow me on Twitter, you probably already knew that I attended DEFCON 30 in Las Vegas.
If you were there in person, you probably also saw this particular nerd walking around:
The collar reads “Warning: PUNS” in a marquee.
In addition to being shamelessly furry and meeting a lot of really cool hackers (including several readers of this blog!), I attended several village talks (and at least one Sky Talk).
For some of these talks, I attended in fursuit. For others, I opted instead to bring my laptop and take notes. (Doing both things is ill-advised because it’s hard to type with paws, and the risk of laptop damage from excess sweat gives me pause, so it was one or the other.)
To be terse, my DEFCON experience was overwhelmingly positive. However, one talk at the Quantum Village had an extremely sus abstract (which was pointed out to me by Cendyne), so I decided to attend in person and see for myself.
Unfortunately, my intuition as a security engineer did not let me down, as we’ll explore below. But first, some background information.
What is DEFCON, Exactly?
(Feel free to skip this section if you already know.)
DEFCON is a hacking and security conference that takes place every year in Las Vegas, NV.
Unlike the stuffy Industry- and vendor-oriented events, DEFCON is more Community focused. Consequently, DEFCON has an inextricable counterculture element to it, and that makes it unique among security conferences.
(Some of the Security BSides events may also retain the same counterculture attitudes. However, that depends heavily on the attitudes of the local security/hacking scene. Give them a chance if you live near one, or consider starting your own.)
Put another way: DEFCON is to punk rock what USENIX is to classical. You’ll find good practitioners in both genres, and a surprising amount of overlap, but they can be appreciated independently too.
Which is why very few people balked at a group of furries running through Closing Ceremonies.
https://twitter.com/DCFurs/status/1558947697469448192
The weirdness and acceptance of DEFCON is a reflection of the diversity of the infosec community, and that’s a damn good thing.
In addition to DEFCON’s main track, there are a lot of so-called Villages that focus on different aspects of hacking, security, and the community.
For example, the Crypto & Privacy Village.
One of the many aspects of DEFCON is that you find yourself surrounded by people with deep expertise in many different areas (not just technological) who aren’t afraid to call you on any bullshit you spew. (Some of this fearlessness may be due to how much alcohol some people consume at the conference; I generally don’t drink alcohol, especially when fursuiting.)
Vikram Sharma’s Talk at the Quantum Village at DEFCON 30
The M.C. of the Quantum Village introduced Vikram by saying, “You should know who he is,” and saying that he’s deeply involved in policy discussions with government agencies. He was also described as a TED speaker.
https://www.youtube.com/watch?v=SQB9zNWw9MA
I came to the talk intentionally unfamiliar with Vikram’s previous presentations, and with an open mind to the material he was going to share, so to avoid preconceived notions or unconscious bias as much as humanly possible.
The M.C.’s introduction primed me to expect a level of technical competence with cryptography and cryptanalysis on par with, or better than, a typical engineering manager that oversees cryptographers.
Vikram’s talk did not deliver on this built-up expectation.
Vikram Sharma’s Arguments
Vikram’s talk can be loosely distilled into a few important points:
- Cryptography-Relevant Quantum Computers are coming, and we don’t know when, but most experts believe within the next 30 years (at most).
- Although NIST has been working since 2015 on post-quantum cryptography, the advancements in cryptanalysis against Rainbow and SIKE highlight how nascent these algorithms are, and how brittle they may prove to be against mathematical advancements.
- In order to be ready to defend against Quantum Adversaries, we must adopt a mindset of “crypto agility” when engineering our applications.
- For enterprise customers, a Key Management Service that uses Quantum Key Distribution between endpoints in addition to post-quantum cryptography is likely necessary to hedge against advancements to post-quantum cryptanalysis.
The first two points are totally uncontroversial.
The third is interesting, and the fourth is a thinly-veiled sales pitch for Vikram’s company, QuintessenceLabs, rather than a serious technical argument.
Let’s explore the latter two points in more detail.
“Crypto Agility” From an Applied Cryptography Perspective
Protocols that utilize “crypto agility” are not new. SSL/TLS, SSH, and JWT all permit some degree of flexibility in the ciphersuite selection, rather than hard-coding the parameters.
For earlier versions of SSL/TLS, you could encrypt with RC4 with SHA1, and that was totally permitted. Stupid, but permitted. Nowadays, we use AES-GCM or ChaCha20-Poly1305 with TLS 1.3.
The story with SSH is similar, and there’s a lot of overlap in the user experience of configuring SSL/TLS for webservers and configuring OpenSSH. Even PGP supported different ciphers and modes. Crypto agility was the norm for many years.
JSON Web Tokens (JWT) is the perfect example of what happens when you take “crypto agility” too far:
- An attacker can change the
algheader’s value tononeto allow for trivial existential forgery. This surprises users. - An attacker can take an existing token that uses an asymmetric mode (
RS256,ES256, etc.), change thealgto a symmetric mode (i.e.HS256), then use the public key (or a hash of the public key) as a symmetric key, and the verifier would just blindly accept it.
When you maximize “crypto agility”, you introduce dangerous levels of in-band protocol negotiation.
Crypto Agility tends to become a security problem: When an attacker can entirely decide how the target system behaves, they can often bypass your security controls entirely.
Therefore, anyone who speaks in favor of crypto agility should be very careful about what, precisely, they’re advocating for.
Vikram’s talk wasn’t clear about these nuances. At the opening of the Q&A session, I asked the following question:
How do you balance your proposal for crypto agility with the risks of in-band protocol negotiation?
He declined to answer this question directly. Instead, he directed me to email his CTO, John Leiseboer, adding, “He would be better able to speak to that.”
So I returned to my DEFCON hotel room and sent an email to the email address that was displayed on Vikram’s slideshow.
Soatok’s First Email to QuintessenceLabs
This was mostly an attempt to be diplomatic so as to not scare them off from responding:
Hi,I attended your CEO’s talk at the Quantum Village at DEFCON 30. I was very interested in the subject, and Vikram’s delivery of the material was appropriate for the general audience. I did have one question, but he suggested that would be better answered by your CTO.
For a bit of background: I work in applied cryptography.
My question is, “How do you balance your proposal for crypto agility with the risks of in-band protocol negotiation?”
To add color to this question, consider the widely exploited standard, JSON Web Tokens. To change the cryptographic properties of a JWT, you only need to change the “alg” header. This is maximally agile.
Unfortunately, you can specify “none” as an algorithm. This surprises users: https://www.howmanydayssinceajwtalgnonevuln.com/
Additionally, an attacker can take a token signed with an asymmetric key (e.g. RSA), change the alg header to HMAC, and then use [a hash of] the asymmetric public key as if it were a symmetric HMAC key, and achieve trivial existential forgery.
The same concerns, I feel, will crop up when migrating to a hybrid post-quantum design. Cross-protocol interactions of the incorrect secret keys would, from by understanding of Vikram’s talk, be made possible if an attacker can mutate the metadata table.
There is a way out of this mess: Versioned Protocols. Using JWT as an example, a contrary proposal that can support cipher agility but only for ciphers (and constructions of ciphers) that cryptographers have approved is called PASETO. https://paseto.io
If a vulnerability in the current supported protocols (v3, v4) is discovered, the cryptographers behind PASETO will specify new modes (e.g. v5 and v6). Currently the only reason they’re considering any such migration is for hybrid post-quantum signatures (P384 + Dilithium, Ed25519 + Dilithium).
I think the general idea of crypto agility is the right direction for addressing the risk of cryptography relevant quantum computers, but I would caution against recreating the protocol foot-guns made possible by the wrong sort of agility.
Vikram suggested you would be able to speak more to how your designs take these threats into consideration. I’m very interested in this space and would love to learn more about how your designs work at a deeper level.
Thank you for your time,
Soatok
(Typos included in original email)
I didn’t hear back from them for several days, so I hunted down the CTO’s email address directly (thanks, old mailing list discussions!).
He quickly responded with this:
John Leiseboer’s First Response Email
Hi Soatok,My apologies for not responding sooner. I’ve been travelling and in meetings across three time zones. It’s been difficult to find time to absorb your questions and put together a response.
Please give me a few more days to find some time to get back to you.
Regards,
John
I want to pause here and make something very clear: My actual question is the most basic and obvious question any credible security engineer that works with cryptography would ask in response to Vikram’s presentation.
If you were to claim, “Everyone should use crypto agility,” and don’t qualify that statement with nuance or context, then a follow-up question about the risks of crypto agility is inevitable.
If this question somehow doesn’t come up, you’re in the wrong room of the wrong security engineers when you rehearse your pitch.
Why, then, would the speaker not be prepared for such a question? Isn’t he routinely offering similar talks to policy experts for government agencies?
Why, also, would his company’s CTO not be able to readily answer the question without needing additional time to “absorb” this question and put together a response?
It’s not like I asked them to provide a machine-verifiable, formal proof of correctness for their proposals.
I only asked the most basic Cryptography Protocol Design 101 question in response to their assertion that “crypto agility” is something that “companies” should adopt.
The proof, the proof, the proof is invalid!We don’t need no lemma–Proof by contradiction fail!
Fail, contradiction, fail!
With apologies to Rock Master Scott & The Dynamic Three
Was this company’s leadership blind-sided by the most basic question of the field of study they’re hoping to, at least in part, replace?
Did they fail to consider an attacker that alters the metadata associated with their encrypted data in order to convince the “agile” cryptosystems to misbehave?
I will update this post when I have an answer to these very interesting questions.
(Update) QuintessenceLabs Responds
This is one email, but I’m going to add my commentary between paragraph breaks.
Hello again Soatok,I’ve just read your blog where you criticised Vikram’s DEFCON talk. I was disappointed that you couldn’t wait for me to get back to you with the more detailed response that I promised to provide you last night.
Mea culpa. If I don’t press “publish” when the iron is hot, these posts stay in rough draft hell for 12-15 months, and I wanted to get my feedback (and the necessary context for said feedback) to the Quantum Village.
The short answer to your question, “How do you balance your proposal for crypto agility with the risks of in-band protocol negotiation?”, is simply that our proposal does not permit in-band negotiation. I suppose I could have provided you with that simple answer, but I expected that you’d want more than that. And I certainly wanted to provide you more. So, with apologies to Winston Churchill, if I had more time I would have written a shorter response.The problem with the term “crypto agility” is that it means different things to different people. In your case, you talk about the “crypto agility” of SSL/TLS, SSH and JWT. The problem, as you are aware, and point out in your email and blog, is that crypto agility, as implemented in these protocols, introduces security issues. At QuintessenceLabs we are well aware of the issues arising from the sort of crypto agility that provides too much flexibility to users (and attackers are a class of user as far as I’m concerned), and fails to account for imaginative use of the agile features.
Although I do not yet have access to Vikram’s slides, I will point out that the specific example used during the talk included encrypted credit card numbers and a separate metadata table that stored the algorithms used to encrypt said credit card numbers.
(He specifically spoke to upgrading from AES-128 to Kyber; which I thought was an odd proposition considering Kyber is a KEM not a symmetric cipher, but I dismissed that as misspeaking.)
Vikram’s metadata table proposal necessarily implies some kind of in-band negotiation, which is the bad type of crypto agility.
The following is taken from the introduction of an internal QuintessenceLabs Technical Note:“The term “cryptographic agility” is defined within QuintessenceLabs as a key management capability that permits the coding of software applications without the application code needing to specify or refer to specific cryptographic algorithms, key lengths, modes of operation, or similar cryptographic details. This capability enables applications to migrate between key types and cryptographic algorithms without a need to update the application software.
Specification of key types, strengths, modes, and cryptographic algorithms, etc. is the responsibility of a key management administrator. The key management platform delivers key material and meta data to applications in such a way that the cryptographic service or library used by the application can perform cryptographic operations in accordance with the attributes attached to the key material.”
This would have been very useful to include in the DEFCON talk. (It would have also been helpful if the speaker was prepared to answer such questions about the proposal!)
I generally think developers shouldn’t even need to care about the ciphers and algorithms being used; only that they’re secure, fast, and appropriate for their security goals. i.e. While AES-256-GCM might be okay for many use cases, it’s not how you should be storing users’ passwords.
In this regard, it sounds like the actual proposal is closer to NaCl/libsodium’s crypto_box() API, except the underlying library can tolerate algorithm upgrades (e.g. from X25519 + Xsalsa20poly1305 to something like X25519/Kyber768 + XChaCha20 + BLAKE2b-MAC). Which is totally reasonable.
This is very similar to what I did with my open source cryptography library, after all. It wraps libsodium, and if I decided to upgrade it to be post-quantum secure, I could do so without my users noticing (except maybe some bandwidth and performance differences).
The simplest way to tolerate such upgrades, by the by, is to use some sort of versioning scheme (which is the non-agile crypto design), which is what I’ve been proposing all along.
Some key points to note about our implementation:
- The application developer has absolutely no control over which algorithms, key lengths, modes of operation or other crypto-related attributes are used.
- The cryptographic key is actually a “managed object”. It is a protected object that encapsulates the key values and attributes that define how the key is to be used, including attributes such as cryptographic algorithm, key length, mode of operation, permitted uses (e.g. encrypt, decrypt, sign, signature verify, MAC, wrap, unwrap, etc.), links to related managed objects (e.g. a private key has an attribute that is it’s associated public key identifier), not-before and not-after time stamps, and maximum usage limits after which the key must be retired for use for protect operations.
- The cryptographic subsystem (whether that is an HSM, smart card, library, external service, …) presents a very simple API. Again from our internal Technical Note (was this in Vikram’s presentation?):
This is actually reasonable! Per Sophie Schmieg:
https://twitter.com/SchmiegSophie/status/1264567198091079681
“The application code is responsible for the business logic of the application. The application code makes no low level and direct cryptographic calls. Instead, it makes calls that abstract away the cryptographic details.An example of how this may work is as follows:
protected_data = protect(sensitive_data, policy);In this example the sensitive data is the data to be protected, the policy indicates what type of data, or type of protection is required, and the result returned is the protected data. More specifically, the policy could be a template name such as “CCN-Policy”, which might be used for protecting credit card numbers.”
I’m not sure I like this API (protect is way too vague), but the intent is much clearer than some vague notion of “crypto agility”.
The application is responsible for understanding the type of information it is working with. It needs to know whether it’s handling sensitive data or not. It needs to know whether sensitive data needs to be protected. It needs to know the classification of, or how to classify, the data. I think that’s reasonable, after all the application is implementing the business logic.
Why not simply encrypt everything by default and let developers specifically opt out for data classified as not sensitive?
Then if a developer adds a field down the road and somehow forgets to classify it, the database administrator only ever sees ciphertext.
So as the pseudo code above illustrates, the application passes the sensitive data and the classification (encoded in the ‘policy’ attribute) to the cryptographic subsystem to figure out what to do cryptographically.
If you can avoid developers having to even care about these details, while still getting the details right, that’s a win.
- The policy that defines the cryptographic attributes is separately managed. In the case of QuintessenceLabs’ products, this is the responsibility of a key management administrator, or a security officer, who has a cryptographic policy management role.
- The returned, protected data is an object, or structure that encapsulates not only the result of the cryptographic operation, but attributes that allow the inverse operation (“unprotect”) to be performed by the crypto subsystem.
This is actually not clownshoes. Thankfully.
- The policy can be changed at any time. This the agile part of the implementation. Today the policy says use AES-128-CBC, tomorrow is says use AES-256-GCM.
So, a couple of things about this specific example.
- AES-128-CBC is vulnerable to padding oracle attacks.
- If you support both AES-CBC and AES-GCM in the same code path, you can use the legacy CBC mode support to trigger a padding oracle attack to decrypt GCM ciphertexts.
Isn’t cryptography fun?
Adaptive attacks aside, cryptography migrations are way more challenging that your technical description implies. You’re going to have to do the following, in this specific order.
- Make sure your entire fleet can decrypt messages AES-GCM ciphertexts before any machine writes any data using AES-GCM.
- Only after step 1 is complete, you can upgrade your fleet to start writing records with AES-GCM.
- Re-encrypt all old records to use AES-GCM instead of AES-CBC.
- Turn off support for the legacy CBC mode.
If you attempt to move onto step 2 before step 1 is finished, you will find your network in a split-brain scenario where freshly-encrypted data cannot be read by some machines.
If you attempt to move onto step 3 before step 2 is finished, you will find some machines are still writing the legacy format.
If you attempt to move onto step 4 before step 3 is finished, you will lose access to some subset of old encrypted data.
It’s simply not possible to design a “crypto agile” application at any significant scale that totally avoids any window of downgrade susceptibility without also losing access to old encrypted data.
Until your entire network has reached step 4, you’re necessarily going to be vulnerable to in-band negotiation.
Also if you’re using the same key for multiple records (or the same wrapping key for multiple data keys), you’re going to read up on symmetric wear-out and the birthday paradox.
HKDF helps, but it has a specific way it needs to be used in security proofs.
Obviously as new algorithms are introduced, the crypto subsystem will need to be upgraded. But the application should not have to be changed.Please feel free to ask more questions. But please be patient. Right now I’m sitting at the check-in gate at Dulles Airport using a laptop with a battery rapidly running down. For the next 30 or so hours I’ll be flying back home to Australia. I’m always happy to receive questions. I would ask though that you have some respect for my time and give me a chance to catch my wind before you publish an article without allowing me the time to respond properly.
The technical details that were absent from the DEFCON talk I watched, which only cryptographers and security engineers will really care about, were essential and should have been included.
I still disagree about the properties of their proposed “crypto agility” in practice (especially at cloud scale, which seems to be where QuintessenceLabs’ CEO wants to operate), but at least this is a much more reasonable proposal.
(The remainder of this blog post remains unchanged from what was written before John’s reply was edited in.)
Against Quantum Key Distribution
While the response to my question about “crypto agility” was disappointing, their argument for Quantum Key Distribution is just weird.
Quantum Key Distribution (QKD) doesn’t scale well enough to protect consumers.
Suppose you’re accessing a brand new computer and want to login to your bank’s website to check your account balance. In this scenario, QKD is useless for you: You haven’t established a secure channel via quantum entanglement yet. You probably don’t even have the hardware or optic channel necessary to do so.
QuintessenceLabs doesn’t acknowledge this scaling issue explicitly in their Quantum Village slides. Instead, they pitch QKD as a solution for businesses (rather than users) that want to add a layer of quantum security to their Key Management Services (described vaguely as “interacting with HSMs”).
I’m not sure who exactly their intended audience is with this sales pitch: Are they trying to sell this to, or compete with, large cloud providers?
Either way, this isn’t the sort of thing that resonates well with most hackers (who are more aligned with protecting users than protecting companies), so DEFCON isn’t really the best venue for such a sales pitch.
To their credit, they don’t entirely handwave post-quantum cryptography as a solution to cryptography relevant quantum computers. Instead, they claim that QKD is an “optional” way to protect communications when post-quantum cryptography is broken. Vikram comes short of describing these algorithmic breaks as “inevitable” in his presentation.
Here’s the rub: QKD isn’t magic.
Just as the correct response to, “What’s your threat model?” isn’t, “Well why don’t you try to disprove Heisenberg? Checkmate atheists!” the solution to quantum computing isn’t to throw all of discrete mathematics out with the bathwater in favor of relying only on quantum entanglement.
Even if you assume that the physical properties being leveraged to secure QKD cannot be directly defeated, you still have to deal with side-channel attacks. Et cetera.
That’s not to say that QKD research isn’t valuable or interesting. But I would strongly caution anyone who’s considering deploying it in production to talk to cryptographers and other security experts first.
Art: Harubaki
Burning Trust at DEFCON 30
DEFCON isn’t at all a vendor expo like Black Hat USA where you send sales drones to hock blinkenboxen that claim to secure networks.
DEFCON is where serious researchers and eccentric geeks exchange 0days for cocktails and solve interesting technical challenges.
https://twitter.com/telechallenge/status/1558891761610723330
My point is: If you present bullshit at DEFCON, you will be called out on it.
When I sat down at the Quantum Village to watch Vikram’s presentation, I honestly wanted it to not be bullshit.
After all, a lot of talented hackers lack refinement in public speaking, especially with talk abstracts. Conversely, a lot of business people (i.e. the CEO of a company) might be so accustomed to writing abstracts for a different audience, even if they ultimately deliver a hacker-focused talk in the end.
Therefore, in my mind, it’s possible that the content of the talk would be surprisingly excellent. Unfortunately, I left disappointed.
I can’t help but wonder if Vikram’s company being one of the four sponsors for the nascent Quantum Village prevented the necessary bullshit filter from being utilized to screen his talk.
He, and his employees, might rightfully claim to be experts on quantum technology, but they certainly don’t understand cryptography as well as they like to believe.
The thought of a sponsor bypassing the bullshit filter certainly makes me a little distrustful of the Quantum Village going into DEFCON 31.
Recommendation for DEFCON 31 and Beyond
The Quantum Village should reach out to the Crypto & Privacy Village to help review any talks that involve cryptography, moving forward.
This will help in two ways:
- Cryptography and privacy experts will be involved in the process.
- Someone who doesn’t have a perverse incentive will likely be involved in the process, which makes it easier to tell a sponsor, “Hell no.”
A particularly motivated bullshit artist with sufficient capital might simply sponsor both villages, so it’s not 100% foolproof, but you can always count on weirdos in fursuits like me to be the last line of defense, should all else fail.
Update:
https://twitter.com/FiloSottile/status/1560165504312135680
I stand corrected. This attack vector won’t work. Thanks, Filippo!
Closing Thoughts
I was originally going to delay publishing this until QuintessenceLabs had a chance to respond to my question, or at least until all of the slide decks were published (so I could cite them carefully in my critique), but I honestly wanted to get my recommendation off my chest and in the hands of the Quantum Village organizers before I get distracted by the work that piled up while I was at DEFCON.
I might blog for free, but that doesn’t mean I don’t have a job to do, or bills to pay.
If you (or someone you work for) were sold on “crypto agility”, consider versioned protocols instead. And if you’re going to invest in custom hardware, take a page out of Nintendo’s book: simply burn fuses with each new protocol version to prevent downgrade attacks.
You probably don’t need quantum encryption to solve any of the problems you face in the immediate future.
https://soatok.blog/2022/08/18/burning-trust-at-the-quantum-village-at-defcon-30/
#cryptographicProtocols #cryptography #DEFCON #inBandNegotiation #JWT #postQuantumCryptography #QKD #QuantumEncryption #QuantumKeyDistribution #QuantumVillage #QuintessenceLabs #QuintessenceLabs #securityEngineering #VikramSharma
Sometimes my blog posts end up on social link-sharing websites with a technology focus, such as Lobste.rs or Hacker News.On a good day, this presents an opportunity to share one’s writing with a larger audience and, more importantly, solicit a wider variety of feedback from one’s peers.
However, sometimes you end up with feedback like this, or this:
Apparently my fursona is ugly, and therefore I’m supposed to respect some random person’s preferences and suppress my identity online.
I’m no stranger to gatekeeping in online communities, internet trolls, or bullying in general. This isn’t my first rodeo, and it won’t be my last.
These kinds of comments exist to send a message not just to me, but to anyone else who’s furry or overtly LGBTQIA+: You’re weird and therefore not welcome here.
Of course, the moderators rarely share their views.
https://twitter.com/pushcx/status/1281207233020379137
Because of their toxic nature, there is only one appropriate response to these kinds of comments: Loud and persistent spite.
So here’s some more art I’ve commissioned or been gifted of my fursona over the years that I haven’t yet worked into a blog post:
Art by kazetheblaze
Art by leeohfox
Art by Diffuse Moose
If you hate furries so much, you will be appalled to learn that factoids about my fursona species have landed in LibreSSL’s source code (decoded).
Never underestimate furries, because we make the Internets go.
I will never let these kind of comments discourage me from being open about my hobbies, interests, or personality. And neither should anyone else.
If you don’t like my blog posts because I’m a furry but still find the technical content interesting, know now and forever more that, when you try to push me or anyone else out for being different, I will only increase the fucking thing.
Header art created by @loviesophiee and inspired by floccinaucinihilipilification.
https://soatok.blog/2020/07/09/a-word-on-anti-furry-sentiments-in-the-tech-community/
#antiFurryBullying #cyberculture #furry #HackerNews #LobsteRs #Reddit
Please enjoy @pluralistic Cory Doctorow's fantastic presentation on taking back the internet from last month at #DEFCON32. Cory's takes are always thoughtful, provocative and it was his deshittification concept that helped inspire the DC32 theme. More videos from #defcon coming soon. As always, pass it on.
DEF CON 32 - Disenshittify or die! How hackers can seize the means of computation - Cory Doctorow
The enshittification of the internet wasn't inevitable. The old, good internet gave way to the enshitternet because we let our bosses enshittify it. We took ...YouTube
"Eradicating Hepatitis C with Bio-Terrorism" - DEFCON 32