This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).
This commit is auto-generated:
$ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
Meta Ports Ladybird Tests Kernel)
$ perl -pie 's/\bDeprecatedString\b/ByteString/g;
s/deprecated_string/byte_string/g' $xs
$ clang-format --style=file -i \
$(git diff --name-only | grep \.cpp\|\.h)
$ gn format $(git ls-files '*.gn' '*.gni')
...for handlers of revision 6.
The spec for this algorithm has several quirks:
1. It describes how to authenticate a password as an owner password,
but it redundantly inlines the description of algorithm 12 instead
of referring to it. We just call that algorithm here.
2. It does _not_ describe how to authenticate a password as a user
password before using the password to compute the file encryption
key using an intermediate user key, despite the latter step that
computes the file encryption key refers to the password as
"user password". I added a call to algorithm 11 to check if the
password is the user password that isn't in the spec. Maybe I'm
misunderstanding the spec, but this looks like a spec bug to me.
3. It says "using AES-256 in ECB mode with an initialization vector
of zero". ECB mode has no initialization vector. CBC mode with
initialization vector of zero for message length 16 is the same
as ECB mode though, so maybe that's meant? (In addition to the
spec being a bit wobbly, using EBC in new software isn't
recommended, but too late for that.)
SASLprep / stringprep still aren't implemented. For ASCII passwords
(including the important empty password), this is good enough.
...for handlers of revision 6.
Since this adds U to the hash input, also trim the size of U and O to
48 bytes. The spec requires them to be 48 bytes, but all the newer PDFs
on https://cipa.jp/e/std/std-sec.html have 127 bytes -- 48 real bytes
and 79 nul padding bytes. These files were created by:
Creator: Word 用 Acrobat PDFMaker 17
Producer: Adobe PDF Library 15.0
and
Creator: Word 用 Acrobat PDFMaker 17
Producer: Adobe PDF Library 17.11.238
This is a step towards AESV3 support for PDF files.
The straight-forward way of writing this with our APIs is pretty
allocation-heavy, but this code won't run all that often for the
regular "open PDF, check password" flow.
This detects AESV3, and copies over the spec comments explaining what
needs to be done, but doesn't actually do it yet.
AESV3 is technically PDF 2.0-only, but
https://cipa.jp/std/documents/download_e.html?CIPA_DC-007-2021_E has a
1.7 PDF that uses it.
Previously we'd claim that we need a password to decrypt it.
Now, we cleanly crash with a TODO() \o/
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Security handlers manage encryption and decription of PDF files. The
standard security handler uses RC4/MD5 to perform its crypto (AES as
well, but that is not yet implemented).
