Live data from Hacker News

Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

usenix.org

121–130 of 158 posts

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#121

Earlier quoted context omitted.

You’re assuming the key is 256 random bits, which is almost certainly untrue for a human-rememberable password. The 16 bytes of salt are public, and AES is designed to be _fast_, so this scheme is horribly insecure for password-based security.

It doesn't need to be 256 random bits. The chosen design smears the key, so if your password has 10 bits of randomness, my best attack is to try those 10 bits worth of passwords. That is practical to try, but if I have enough bits you might as well just guess keys, which you can't do, so, game over. It does need to be actual randomness, so "NameOfCorp" won't work to protect Corp's documents, but people need to get ov…

> 44 bits of randomness might be feasible for a serious attacker, while maybe if it was 1000 times harder they'd give up

My back-of-the-napkin math[^1] says that, on an AMD Ryzen 7 1800X (released in 2017), brute-forcing 54 bits of entropy in AES-256-GCM takes an average of about 2.6 months. That’s on (pretty outdated) consumer hardware, not GPUs, specialized ASICs, or parallelizing across different machines. That’s considered outrageously insecure in the infosec world - anyone with a few thousand dollars to spare on cloud computing can crack.

> a fancy stretching algorithm won't make terrible passwords good

A properly tuned password-hashing algorithm like Argon2 should take about 1 second per hash, and can be configured to eat as many cores and memory as you expect the attacker to have/you feel like dedicating to hashing. Let’s assume you dedicate 2 cores to each hash (a relatively conservative value) - that same 54 bits of entropy now takes an average of 71 million years to crack[^2]. You’d literally be better off trying to brute-force the full AES-256 key space, after the key derivation step (which is the whole point of Argon2 and similar algorithms).

Dangerous advice like you’ve just spouted is against every single password hashing guideline out there - please trust the cryptographic community, they do in fact know what they’re doing when designing algorithms (or at least they know better than you).

[^1]: 2642 MBps per core (https://calomel.org/aesni_ssl_performance.html) = 165 million 128-bit blocks per second per core = 1.32 billion 128-bit blocks per second -> 6.82 million seconds to try 2^53 combinations (50% chance of success) = roughly 2.6 months

[^2]: 1 hash per second per 2 cores = 4 hashes per second -> 2.25e15 seconds to try 2^53 combinations = 71 million years

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#122
post #91

Earlier quoted context omitted.

Here in Norway, I've had to use my banks 2-factor BankID[1] to sign my loan, house purchase contract etc. According to their documentation[2] it absolutely relies on cryptography, including SEID-SDO[3] [1]: https://www.bankid.no/bedrift/bankid-signering/ [2]: https://confluence.bankidnorge.no/confluence/pdoidclc/techni... [3]: https://www.nets.eu/developer/E-Signing/overview/Pages/Signe...

That's interesting, thanks, but I am specifically interested in the US (like the thread I was responding to).

Sure, I just like to bring an outside perspective when I can.

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#123
post #11

> For documents of prime importance, such as contracts and invoices Few in the legal world actually use cryptographic signatures for signing things. It's vastly more common to use scanned hand signatures or just /s/ and an e-mail record of sign off. Why? Because it has worked that way for hundreds of years. It's pretty uncommon for there to be a dispute about the fact of signature, and even if there is, cryptographic…

Same thing with the notarization system. Is the notary system foolproof? Absolutely not! Imagine how much better notarizations could be with a bit of technology around it. A digital notary could take a photo of your document, register a hash/summary/thumbnail in realtime, and make it so that backdating or changing the document after the fact is a technical impossibility. What do we use instead? A guy who's probably e…

It really comes back to that xkcd - https://xkcd.com/538/ - doesn't it?

Systems designed by and used by humans will always have at least one fault - the humans involved.

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#124
post #11

> For documents of prime importance, such as contracts and invoices Few in the legal world actually use cryptographic signatures for signing things. It's vastly more common to use scanned hand signatures or just /s/ and an e-mail record of sign off. Why? Because it has worked that way for hundreds of years. It's pretty uncommon for there to be a dispute about the fact of signature, and even if there is, cryptographic…

In some countries digital signatures are used in vast majority of cases, paber being the rare fallback (and nobody scans or faxes those).

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#125
post #88
post #78

Earlier quoted context omitted.

They also don't want to share two files, one for the file, one for the signature. Ideally, it's integrated, which means there needs to be some management. And ideally, it's also applied to the data before it's compressed, so that you can apply advanced compression and deduplication to archived documents like zopfli for example.

Isn't docx literally a zip file?

Yes, and with zopfli you could theoretically reduce the size, but signatures are on the whole file, and will be destroyed.

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#126
post #12

Earlier quoted context omitted.

At least in Europe, electronic signatures of a certain form are legally equivalent to handwritten signatures [0], and are increasingly used as such. Emails don’t provide that legal value. [0] https://en.wikipedia.org/wiki/EIDAS

I’ve found the per-country overview of general legality of digital signatures on DocuSign [0] quite informative. As an example, in DK an email constitutes a valid contract for most purposes. [0] https://www.docusign.com/products/electronic-signature/legal...

Looks useful.

However, when you read the page about Finland it suddenly starts talking about Austria.

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#127
post #54

Signed OOXML Word files are ZIP files defined by what appear to be 3 manifests: a content-types.xml file, a document.rels.xml file that maps symbolic IDs to filenames, and the "Package Info" section of the signature block, which supplies hashes for all signed files. The rendering of an OOXML Word file starts from "document.xml". Here are the attacks, as I understand them: 1. OOXML doesn't sign content-types.xml. It a…

The container used for OOXML documents is the Open Packaging Conventions format, which is well-specified.

It has a .NET library: https://learn.microsoft.com/en-us/dotnet/api/system.io.packa...

An ECMA standard: https://www.ecma-international.org/publications-and-standard...

Etc...

This is pretty convenient for writing utilities to parse MS Office documents correctly on platforms such as Windows Server Core or Linux, where the actual Office applications are not installed.

Care must be taken because the format isn't "just" XML in a Zip container. Large documents can be fragmented and interleaved..

What's sad is that the format is 90% of the way there to a really good generic document container format. It solves many common problems, such as streaming decode and incremental saving. It also "solves" signing, but as we can all see, 90% secure is 100% insecure.

A modern version would be akin to the Docker container format: JSON metadata inside a gzip file referencing binary blobs with relative paths and SHA signatures.

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#128
post #93

Earlier quoted context omitted.

I don't know about other places; but in the UK, a contract doesn't even have to be written down, let alone signed. Of course, an unwritten contract is no more valuable than the paper it's (not) written on; and either party can dispute the terms. But you can still make a valid contract with a verbal agreement and a shake of hands. But don't do this unless you trust your co-contractor!

In most places, if there are witnesses to a contractual obligation being established or contract being performed, even a verbal agreement can be sufficient. It mostly depends on how quickly courts will do the proceedings to establish that it is or isn't so.

The phrase, "this is a bag of good old oats," springs to mind.

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#129

"Signed documents" are a joke and everybody knows it. As the XKCD goes: How to use PGP to verify that an email is authentic: Look for this text at the top -----BEGIN PGP SIGNED MESSAGE----- If it's there, the email is probably fine The abstract only mentions it offhandedly, but I think the least emphasized bug in their paper is actually the most important, because it really drives this point home: "We discovered that…

Hey, what do you expect, it's only Pretty Good Privacy, not Actually Good Privacy!

Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures

#130

Earlier quoted context omitted.

On "serious" contracts, it's common to put your initials on each page, or to fan out the stack of papers and sign the margin so that each page contains part of that signature. Both are in addition to the "real" signature at the end, and provide some protection against exactly these kinds of problems. I guess a cryptographer would add a hash of all preceding pages on the last page.

> I guess a cryptographer would add a hash of all preceding pages on the last page. That's basically how hashes and signatures work anyways. They basically take in the result of the previous block and integrate it into the new block so that if you change any part of the previous parts, the whole thing breaks. Edit: I should specify this is how the algorithms themself work. Implementations can fuck this up (and they d…

There are also Merkel trees, which are closer to the signature -on-"subdocuments" mentioned above. Also blockchains that explicitly include the previous block's hash.
Post reply on HN