6,663 karma · joined February 25, 2016
Previously AWS Cryptography (2019 - 2023).
Unless otherwise stated, my opinions are my own and do not reflect my employer.
https://scottarc.blog/about/
Wired: {"alg":"nonE"}
The JOSE standards (including JWT) are a gift that keeps on giving to attackers.
I designed an alternative format in 2018 called PASETO, which doesn't contain the JOSE foot-guns. (I'm pushing for an IETF RFC this year.)
EDIT: Also, this affected their Authentication API rather than their JWT library.
If you use their JWT library, well, it certainly allows this kind of horrendous misuse... but it is not, per se, vulnerable.
[ App (Java -> Dvorak) ]--.
>--- Same CPU
[ Web Browser with JS ]--`
The details you probably want me to put here are a bit fuzzy still, and I've solicited others' to provide clarity and insight into the specifics, so I apologize if this is hand-wavy, but your question deserves an answer.
Given:
Most smartphones are built on ARM architecture. At the very least, I'm confident about Android being ARM. I've never purchased an Apple product in my life, and can't rightly say much about their internals.
ARM before ARMv8-A did not provide hardware AES. https://en.wikipedia.org/wiki/ARM_architecture#ARMv8-A
Adiantum cites the Cortex-A7 as one example processor that does not provide hardware-accelerated AES: https://security.googleblog.com/2019/02/introducing-adiantum...
"In order to offer low cost options, device manufacturers sometimes use low-end processors such as the ARM Cortex-A7, which does not have hardware support for AES. On these devices, AES is so slow that it would result in a poor user experience; apps would take much longer to launch, and the device would generally feel much slower."
Even for smartphones that use ARMv8-A and newer, OEM weirdness can get in the way of that. Without tearing a specific model of a specific phone apart, I can't really give you much more information than that.
The advantage to the additional risk of ChaPoly is to not cough up keys to JavaScript running in a web browser capable of leveraging a cache-timing attack against software AES, in the smartphones that most people can afford.
That is to say, while it's true that the CSPRNG failure mode of ChaPoly is bad (but relies on conditions the attacker probably can't control), the failure mode of software AES is equally bad and can be influenced by an attacker.
> In a new design, I'd recommend Chapoly too. But this isn't a new design. Changing things has cost.
If there is significant market share where the device has a reliable CSPRNG but not hardware AES (post-OEM tampering), I'd argue that the security gain of a ChaPoly migration is worth the cost of changing, in particular.
The ratcheting changes are mostly a hygiene issue and probably won't be meaningfully important. I was just being nitpicky.
(a.k.a. isn't happening)
(N.b. I don't expect my specific suggestions to be adopted. However, I view complaining without offering solutions to be poor form, so I offered some alongside my complaints.)
Of course, any deviation from Signal's design can and should be vetted by the same experts that vetted Signal's. And if they're unavailable to vet the derivations, the conservative thing to do is grit your teeth and bear Signal's legacy until they become available.
However, if Signal still targets Android 4.4 phones in 2020, there's a lot of devices without AES-NI and thus improving upon their AES-CBC design decision is worth probing at least.
I'm literally referring to "the iMessage attack".
If you recall, iMessage did ECDSA(AES(m, ek), sk) without an intermediary HMAC. Libolm does have an (albeit truncated) HMAC, so the attack doesn't apply at all here. But it's still a design smell.
If I could extend their construction (which looks like the setup to the iMessage attack, without the punchline) into a real attack, I would have just disclosed it to them and not commented publicly.
How the attack I envision would work if their HMAC suddenly got erased from the protocol: Establish a multi-device setup, flip bits in ciphertext you want to decrypt, sign with Ed25519, observe padding oracle.
(A truncated HMAC does prevent that in the real world, but at a 32-bit security level rather than a 128-bit security level.)
These are (somewhat nitpicky) design critiques, not security vulnerabilities. :)
Edit to add: Also, the iMessage attack had some other weirdness that isn't relevant for what I'm describing, but was very relevant for iMessage being broken.
Because the only premise for strictly adhering to the Signal protocol has been invalidated by Moxie's personality.
With a false premise, why maintain a true conclusion?
In my OP comment, I outlined some criticisms of what they're doing, and suggested ways to improve it. Some of these (dropping AES-CBC+HMAC for AES-CTR+HMAC) have meaningful gains but, strictly speaking, are not Signal-compat.
The change to the ratcheting protocol adds a layer of indirection in the forward secrecy, but that also deviates from Signal. (My proposed change would make it closer to what the Noise Protocol Framework does.)
> Which requirements are different?
The technical requirements aren't changed, but you can get better performance AND security on more platforms by using XChaCha20 instead of AES-CBC, so that's a meaningful security gain that Signal cannot boast (i.e. in the context of legacy Android devices).
https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03
It's fast and constant-time even on mobile devices (where AES is often variable-time or slow due to a lack of AES-NI).
My reasoning here is: Moxie isn't ever going to acquiesce on the points he's stubborn about, and Olm/Megolm could otherwise be a great cryptographic design with or without his approval.
> What don't you like about the variable names at https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e... ?
Confusion between ciphertext on line 85 and output on line 89 made me have to reread the function twice to figure out what was going on.
I have a number of critiques of libolm that I haven't developed into a practical attack, but are simple enough to fix (if you ignore the massive legacy support and backwards compatibility t̵r̵a̵p̵ ̵t̵h̵e̵y̵'̵v̵e̵ ̵s̵e̵t̵ ̵f̵o̵r̵ ̵t̵h̵e̵m̵s̵e̵l̵v̵e̵s̵ EDIT: see Arathorn's comment below).
Libolm is encrypting with AES-CBC [1]. In addition to side-stepping entire classes of attack (i.e. padding oracles), CTR would allow better performance: You can parallelize both encryption and decryption with CTR mode. With CBC mode, you can only parallelize decryption (but not encryption) since the IV for all but the first block is the previous block of ciphertext, which means you'll know the correct IV when decrypting but not when encrypting (since you have to calculate it sequentially).
Yes, they HMAC the ciphertext [2]. However, their variable name choice doesn't inspire confidence in its correctness.
Furthermore, they truncate the HMAC to 8 byes and attempt to justify the truncation by appending an Ed25519 signature, but that sort of configuration is just begging for a confused deputy scenario, like an old iMessage vulnerability [3]. It's no where near as bad (iMessage eschewed MACs entirely, this still uses a MAC, so it's not exploitable), but it's something that probably would make anyone working in cryptography (and any adjacent fields) give a confused puppy head tilt when they read it.
Regarding their ratcheting protocol [4]: Instead of feeding HMAC-SHA256 back into itself at each ratchet step, I'd feel way more comfortable if the protocol did HMAC-SHA512 and used one half of the output to derive encryption/authentication keys and the other half the ratcheting-forward key (instead of one HMAC-SHA256 for both purposes).
Using two distinct 256-bit secrets (even if they're generated from the same input at i=0) instead of reusing a secret strengthens the forward secrecy of the entire protocol.
HMAC-SHA256: One ring to rule them all (at any given ratchet step).
HMAC-SHA512-split: If you (against all odds) guess one of the keys, that doesn't give you the ratchet-forward key too, since they're two distinct keys (albeit generated deterministically from the same input).
Nothing I said above is exploitable, otherwise I'd be emailing their security team instead of posting on HN. :)
That being said, if the Libolm devs want to shore up the security of their protocol in a future revision, the following changes would go a long way:
1. Use HMAC-SHA-512 and split it in half for the ratcheting step of Olm/Megolm
2. Use AES-CTR instead of AES-CBC
3. Stop truncating MACs
[1]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...
[2]: https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e...
[3]: https://blog.cryptographyengineering.com/2016/03/21/attack-o...
[4]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...
I should probably have added, before that comma, "threatening my employer".
I've had vuln disclosures go bad before and after the rise in popularity of bug bounty programs, so I'm probably qualified to chime in here.
Before HackerOne, the default for a company that didn't receive vuln reports well was to threaten you and/or your employer with lawsuits.
This happened to me with Bullhorn and Intuit, despite my investigation and reports being unrelated to my employment. They ultimately went no where, but I imagine the conversation I wasn't present for was, at best, awkward.
Last year, under one of my aliases, I found a vuln in Credit Karma, and the H1 triage staff declared it out of scope. So I posted it on Github/Twitter.
Instead of threatening to sue, CreditKarma asked me to pull the tweets/gists and walked back the H1 triage decision and ultimately awarded a bounty for my finding.
Thus, I don't buy the chilling effects narrative the article tries to sell. It actually made security research more normalized than it used to be.
Just my unsolicited $0.02
O RLY?
https://git.jami.net/savoirfairelinux/ring-client-android/is...
https://security.stackexchange.com/a/171461/43688
I looked through their code to see where data is being encrypted/decrypted, and was unable to locate it.
Since their issue indicated they use 4096-bit RSA, I really wanted to see if they were vulnerable to Bleichenbacher's 1998 padding oracle attack.
https://git.jami.net/savoirfairelinux/ring-project/wikis/tec...
> The SHA-1 fingerprint (160-bits) of this public certificate is the JamiId.
this-is-fine.mp4
Infinite.
That's because the set of possible vocations is only bounded by human imagination. This results in an uncountable set, which would resolve to a value that approaches infinity.
A more insightful question is, "How many of the jobs that people hold today can be done at home?" 34% seems like a reasonable metric.
No.
And even if you tried to argue that, the exploit was public on exploit-db for years, and therefore the expected security from the broken obfuscation is zero bits; so in this case, it would not count.
More pertinent:
> Authentication Not required (Authentication is not required to exploit the vulnerability.)
Are they discussing national secrets over Zoom? Without end-to-end encryption?! That's some form of criminal negligence and/or mishandling of classified information in every jurisdiction I know.
If not, it's little more than a nuisance and a reminder that Zoom should not be relied on for important communications.
I haven't really thought about that angle since, either.
My proposal would require companies to actually take security very seriously.
https://www.troyhunt.com/we-take-security-seriously-otherwis...
I never said or implied that.
All I said is, because all of my conduct involved publicly accessible components of their web application, I never exceeded authorized access.
Which means that the CFAA's clause about "unauthorized access" in particular does not apply, since none of my packets exceeded or bypassed an authentication or authorization control on their web app.
> Most homes are accessible from public roads, that doesn't mean you are allowed to climb through any open window that you see.
A better analogy is knocking on someone's door, only to discover it swings open, then walking away. And then getting charged with breaking and entering for their failure to shut their door, and then paying for damages for leaving a muddy footprint on their exterior welcome mat.
> You used a vulnerability to hack into some server associated with the FBI, I don't see any ambiguity here.
I won't argue that I'm fully without blame.
The mistake I made during all of this was, upon discovering they were running an outdated version of DotNetNuke (right click > view source; not exactly something I had to go out of my way to detect), I panicked. And to assuage my own anxiety, I tested the file upload to confirm that it was real.
That was the mistake that let them prosecute me at all. And it's a mistake I have learned from:
In the years since, I have never sent a packet with security implications to another network even for projects with a public bug bounty. I constrained myself henceforth to reviewing source code and reverse engineering, since that doesn't involve sending packets over a network and invoking a law that was written before the concept of a public network existed. (And that law being problematic is my entire point in this discussion, not appealing for amnesty in the opinions of HN users. Anyone who decides to hate me won't be the first.)
Even if I knew not to do that then, I still would have informed them of their vulnerability as soon as it was discovered. Because that was the right thing to do.
This also happened in the state of Florida, which has very open records.
Sylint pressed the charges through the FBI.
Originally, they also insisted I caused damage days before the date of incident and tried to tack on $32k in damages. I pointed out that I do not possess a time machine, and they shifted it from (June 18-24) to (June 21-27) and lowered the dollar amount to $9k.
Employment!
I tried to go the crypto consultant route in recent years and was told by many people via Twitter/Reddit private message that they can't or won't go with the company I helped start simply because of my criminal background.
I spent most of last year job-searching. I interviewed well, but many companies rescinded offers after my background check concluded, even when I told them about this incident up front.
In 2011, everyone joked that I'd be fine. "The government will probably follow up with a job offer," they insisted. Instead, I was rendered unemployable by most of the companies that desire the skills I possess.
The silver lining is that some companies restrict their background checks to a time-gate, which means it's not totally impossible to make a living. But they're the minority.
> Is it directly related to the charges or is it the outcome of spending time behind bars?
My sentence was probation and a short duration of house arrest, community service, and paying Sylint $9,370 (which, at barely above minimum wage, took a few years). My probation was terminated early for good behavior.
The problem has less to do with the courts and more to do with background checks.
People make mistakes. Especially young people. (I was 21 when this happened.)
Learning itself is a messy process that often requires making mistakes to be successful.
Punishing someone in perpetuity for having not lived a perfect life is a problem that society hasn't yet solved.
We have hacks ("Right to be Forgotten") to try to alleviate some of the symptoms, but with the advent of the Internet, there is now a public, immutable record of your most embarrassing fuck-ups. And I don't think we were ready for that.
I've been saying this for years! For reasons unrelated to TOS rulings, too.
A little bit of background...
In 2011, I was charged with unauthorized access to a protected computer. The website in question (Infragard Tampa Bay, run by the FBI through a company called Sylint) was running an older version of DotNetNuke that had a 2008 vulnerability.
The nature of the vulnerability was as follows: If you accessed a specific URL which required no authorization, you could upload files to the server and presumably execute them. (I say presumably, because I didn't.)
I wanted to fight the charge because I never exceeded "authorized access" by using a publicly accessible web form on the public Internet, and the CFAA's terms were vague.
* The website was publicly accessible, without needing authorization
* The file upload form was publicly accessible, without needing authorization
* The folder that files were uploaded to was publicly accessible, without needing authorization
* All of my conduct was authorized by the software they ran on the public Internet, and therefore the unauthorized access I was accused of never actually occurred
My overworked public defender didn't have any fight in him. The EFF wouldn't help either (the person I talked to didn't see the significance of this CFAA ambiguity for civil rights). I grew up in a poor family and couldn't afford legal counsel, so I ended up pleading guilty, which has totally fucked my life up ever since. (It really doesn't get better, even 8-9 years later.)
> since I know many cases in the past relied around users doing shit that was unauthorized by the TOS.
Good. I hope this becomes a precedent that frustrates prosecutors and helps defense cases in appeals court.
1. A lot of folks are being forced into it, rather than it being an option chosen voluntarily.
2. School is cancelled, so kids are home, which can be very distracting for parents (which, for some industries, is a significant portion of employees).
At the intersection of the two observations, I'd caution against extrapolating too much from the recent pain points.
In my experience (I've worked remote for the past 6 years), I'm far more productive working from home than I am in an office.
1. Bullshit. Show us the data to substantiate your claim.
2. Even if we assume that Rutledge is correct: Is the delta in observable effectiveness worth the cost to employees' lives and their families?
I'm on the side of the engineer who resigned. The CEO's policy is stupid, irresponsible, and/or callous.