Rendered at 13:35:06 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
philsnow 1 days ago [-]
It's so insane to have PDF programs doing their own encryption, not because "don't roll your own crypto" (although yes for that reason too), but because the people who write PDF programs (libraries, viewers, general-purpose tools like qpdf, etc etc) aren't (necessarily) going to be great at understanding or designing good encryption UX.
Also, I get that a lot of sensitive information is exchanged with PDFs these days, but why should PDFs have encryption built-in to the file format? Sensitive information is also exchanged in image files, word documents, zip files, html, etc etc etc etc. If you take all the work that goes into making the crypto UX decent for one kind of file and apply that to "all files", then each ecosystem doesn't have to invent their own.
This is just like "high-end" car manufacturers insisting on making their own software, and not integrating apple carplay. They're either going to make a truly shitty podcast app, or they're not even going to bother and instead tell people to use bluetooth to listen to podcasts like it's 2006.
dingaling 1 days ago [-]
> but why should PDFs have encryption built-in to the file format?
Because very few 'end user' people know how to use en/decryption. So it's much easier to send them a familiar file and say 'enter this password' than to have them searching the web to work out which arguments to pass to openssl. In a command line? What's that?
I received an AES-encrypted file recently but neither gnupg nor openssl could determine what mode and keysettings the sender had used, so it was just a useless lump of data. Very secure though...
1718627440 10 hours ago [-]
This should simply be an option in the context menu of the file manager. (And is on my Linux machine)
lmz 1 days ago [-]
Usually the desire is for some of the metadata processing to be reusable between the encrypted and non encrypted formats ("like a regular file, just this data is encrypted"). This is also why eg. Zip files are encrypted per entry, not globally.
Since the kind of data people want available may differ for each file format, here we are.
otabdeveloper4 24 hours ago [-]
> but why should PDFs have encryption built-in to the file format?
So you could open encrypted documents on iOS and Android.
GoblinSlayer 1 days ago [-]
S/MIME?
Avamander 22 hours ago [-]
CDOC2, there are also other similar widely used encrypted container formats.
tptacek 2 days ago [-]
"MuPDF versions before 1.28.5 use an implementation of the drand48 family" yeah, ok, so they're basically not doing real encryption. The number of bits in the key space isn't the real story; the keys simply aren't cryptographically random.
somat 2 days ago [-]
You could do what openbsd did and tie all the traditional weak psudorandom interfaces into a cryptographically secure one. it will still match the drand48() interface. I still don't think I would use them for secure things but now rand() is actually random. http://man.openbsd.org/drand48
Another pet peeve is when people use the rand() when they want hash() but I will leave that rant for another day.
hansvm 1 days ago [-]
I'm interested in that rant (at $WORK we adopted hash() for almost everything, and I'm curious to hear other perspectives).
somat 1 days ago [-]
In my mind rand() (and friends) and hash(thing) (and friends) are almost the same function, with a very similar set of features required, the main difference is that rand() is non-deterministic and hash() is deterministic.
They are so close that people can and often do build rand() as "internal state s = hash(s) return s" (or similar). then other people, wanting that deterministic hash() behavior thus accidentally exposed, build entire worlds(literally) out of rand().
Another problem with this is that the rand() internals are opaque and unknown and can change without violating the spec. hash(), because it is supposed to be deterministic, usually has an exposed stable algorithm.
A specific example. At one job I found they were storing long term customer order archives encrypted where the key was a hash of the date, this in itself is a little suspicious but the archives were offline and physically locked up on site, so not too bad. The real wtf was that the encryption was done on a win98 machine with a perl script that was basically "seed(date); key = rand(); encrypt(data, key)". expecting to regenerate the key if they ever wanted to look at the data. When I saw that I went "I don't know much about perl, but that does not feel stable" and did a few checks. Sure enough the behavior of rand() could change depending on the operating system or even version. making the keys highly dependent on that exact win98 machine with that exact version of perl, I think they ended up using that machine to generate and store all used keys in a database so other machines could decrypt the archives.
lo0dot0 20 hours ago [-]
Encrypted with a key that is a date can be broken by iterating likely dates. Did they add the time up to milliseconds into it or just the date? Not sure if it matters
aidenn0 1 days ago [-]
Per the manpage you linked, openbsd's behavior does not match the drand48() interface, since the drand48() interface requires determinism.
NelsonMinar 2 days ago [-]
What is wrong with software engineers that we keep making really stupid basic mistakes like this? Sometimes I think programming should require licensing and regular testing.
anonymous908213 2 days ago [-]
We direly need to split things into a licensed engineering field which is necessary for working on security- and reliability-critical systems, and a generic unlicensed software developer field where people can screw around with their 1000 dependency JS frontends to their hearts' content. The two should not be conflated and yet so easily are.
greggsy 2 days ago [-]
Certification do exist for engineers, and various industries and governments impose their own certification programs on platforms and software before they’re authorised for use.
Each with varying degrees of trust. The outcome is never perfect, but that’s not their purpose.
nyargh 1 days ago [-]
Credentialism is not a solution, it will just get gamed too. Indian diploma mills and mega IT consultancies pump out thousands of "qualified" engineers every year.
Every hiring manager worth their salt has caught at least one completely incompetent applicant with a CV full of certifications.
GoblinSlayer 1 days ago [-]
Maybe certifications are different? A certified Electron engineer might just read the tutorial how to spend zero effort on apps.
asveikau 1 days ago [-]
One of the problems with cryptography implementations is that a bad one will be indistinguishable from a good one on the surface level. Totally broken crypto will superficially look and work as if it it works, and most people won't look deeply. This has been commented upon for years.
LeoPanthera 2 days ago [-]
This is partly why I'm not too worried about AI slopcode.
The human bar is not that high.
I would much rather have rigorous testing than a filter based on the origin of the code.
hansvm 1 days ago [-]
What's your method for implementing rigorous testing while using AI?
nyargh 1 days ago [-]
Testing doesn't even need to be that rigorous for humans, it's easy to spot someone who is lying about the depth of their experience with a 15 minute conversation.
For AI this will be impossible, however.
If you're talking about testing of code, well "tests can only prove the presence of bugs, not their absence"
rsalus 2 days ago [-]
I think it's safe to assume anything associated with PDFs is radioactive.
HackerThemAll 2 days ago [-]
Those are not the "software engineers" but coders, those who like to say that the university degree doesn't add anything in programming.
anonymous908213 2 days ago [-]
University degrees are not the difference between an engineer and a developer, universities have churned out millions of people who don't care about programming and have no idea what they're doing, who are just following the script with as little effort as possible because they were told it was the easiest way to make a lot of money.
adrianN 1 days ago [-]
You can get through a Computer Science degree with just a few thousand lines of code if you focus on theory courses.
bootsmann 6 hours ago [-]
And how does this disprove their point? I don’t think its the lines of code you write that allow you to decide whether or not you should roll your own crypto…
thin_carapace 2 days ago [-]
a small wonder the wunderkinds of computer science were at all capable given their lack of computer science degrees
Would the new LLM model owners like to strike this down, or use it to demonstrate how dangerous unrestricted models can be?
nextaccountic 1 days ago [-]
there is a case to be made that weak encryption is equivalent to no encryption at all
leni536 1 days ago [-]
Pdfium powers Chrome's/Chromium's PDF viewer, but maybe Chrome doesn't expose encrypting PDF documents as a feature to be affected?
exabrial 17 hours ago [-]
String.getBytes(UTF-8) is an incredibly common way to kneecap yourself
always Base64Encode/Decode!
ubutler 2 days ago [-]
Rule #1 of rolling your own RNG: don’t.
Rule #2? Please don’t.
Mikhail_Edoshin 1 days ago [-]
This translates into "trust some authority", which is also a task. And it does not work when the canned solution does not quite fit, e. g. involves a bulky lib. The true answer should be "use your software engineering textbook and the standard reference of RNGs". Thing is, there is no such reference.
1718627440 9 hours ago [-]
> Thing is, there is no such reference.
man encrypt works. info /encrypt works too.
mik1998 1 days ago [-]
Handbook of Applied Cryptography is a good reference for implementing classic cryptographic algorythms.
j16sdiz 2 days ago [-]
That's why we use the system RNG !
cowlevel 2 days ago [-]
Be careful to use the cryptographic one, not rand(3)
And if you're a sysadmin, be extremely careful when generating keys in VMs or embedded devices. They tend to overestimate their entropy sources - it's possible that every clone of a VM generates the same keys. In some cases (cough ECDSA) generating the same key and nonce to sign two different messages is catastrophic - it immediately leaks the private key.
saidnooneever 2 days ago [-]
good point about VMs. if you run some VPS your provider could just link in a shitty rng into the thing and not give access to the correct hardware rng. U'd really need to dig into that to find out :/.
-object rng-random,id=objrng0,filename=/dev/null
or maybe just a file that contains 4 :O
Novosell 2 days ago [-]
As long as the 4 is random!
saidnooneever 1 days ago [-]
cat /dev/random | grep 4
2 days ago [-]
flanz_10 2 days ago [-]
btw, the idea that the system rng isnt good enough, or "runs out" or whatever, is no longer true on pretty much every modern, widely used os.
btw... im sure there's some legacy rng in windows or some shit that isnt good. read the docs but if it's the blessed system rng, you're probably fine!
although... i suppose if this is news to you (the person reading this), then you probably shouldn't be implementing whatever you are that really requires prng. ask a friend for help. im not trying to be a jerk, i just want to make sure you dont hurt yourself!
ahartmetz 2 days ago [-]
Rule 3: Use as many bits of randomness as the key size.
Rule 3b: Failing rule 3, disclose motivations and full list of employers and / or customers
timerol 1 days ago [-]
Rule 3c: At least as many bits. Bits tend to not be as random as you think they are
snvzz 1 days ago [-]
That's way too many PDF implementations affected by this category of stupidity.
It makes me wonder: Coincidence, really? There's enough there to think that there might be some invisible hand behind it.
I assume this is the fruit of AI-driven decompilation? Nice work.
jeffbee 2 days ago [-]
You'd have to be completely off your rocker to use a PDF tool written in C anyway.
advisedwang 2 days ago [-]
very VERY few people judge tools like this by the language used to develop them.
jeffbee 2 days ago [-]
How many people judge their tools based on the AES key entropy?
OptionX 2 days ago [-]
A lot actually.
You're confusing just assuming by default its enough for purpose rather than not caring at all.
j16sdiz 2 days ago [-]
just down vote it.
You can downvote anything not interesting.
If he have list some alternative or give example, it might be interesting.
cowlevel 2 days ago [-]
What are the alternatives?
crote 2 days ago [-]
PDF.js, for example. It's what Firefox uses, and most websites with integrated on-page PDF viewing functionality.
lirolero 2 days ago [-]
Genuine question, since I'm not very knowledgeable about this: why is using C for a PDF tool such a bad idea?
zamalek 2 days ago [-]
File formats are the buffer issue honeypot. You may be aware of how often video and audio codecs have vulnerabilities - it's nearly never the hand-tuned frame decode assembly (where you would think all the mistakes would be). It's nearly always the thing that reads the metadata and encoded frames to memory. Binary formats have things like offsets in them, and those can be trivially used to overrun.
Same thing applies here. Even Rust has a crate for dealing with binary data, despite its memory promises: https://crates.io/crates/untrusted
It's a fucking minefield, and this is one area where the Rust zealots are undeniably correct. It doesn't have to be Rust, any memory safe language will do, but Rust also happens to be performance competitive and that's usually also desirable.
tialaramex 2 days ago [-]
The technology you want for this sort of work is WUFFS, for Wrangling Untrusted File Formats Safely.
Rust is a general purpose programming language, which is great if your problem might be something never imagined before, but this literally isn't our first rodeo, we have wrangled lots of file formats before, we should use a language purpose-built to do that safely.
zamalek 2 days ago [-]
> Rust is a general purpose programming language
I don't understand how I hit the anti-Rust tripwire here:
> My comment: any memory safe language will do
tialaramex 2 days ago [-]
Not an anti-Rust tripwire. Just that WUFFS is the appropriate technology.
I like 4th edition D&D but if you're trying to make a story about nuanced inter-personal conflict in which there's no actual violence it's just not the right roleplaying system and so I'm not going to agree with your choice to recommend 4eD&D as the system for the story "Love and Jealousy in the Elven Forest"
I've written a whole bunch of Rust, and hardly any WUFFS - but, I wasn't writing code for Wrangling Untrusted File Formats and that's very much what you're doing in a PDF parser.
jeffbee 1 days ago [-]
I am a big fan of WUFFS but some recent developments by people assisted by AIs writing format parsers in other languages has made me question whether it will be maintained or forgotten.
tptacek 2 days ago [-]
I think the claim is hyperbolic, since most people memory-unsafe PDF implementations, but PDF is a monster format, a metaformat that brings in virtually every conceivable display format, and their renderer implementations with them, often poorly-maintained, never-touched reference implementations from the before times. PDF is pretty scary.
DonHopkins 17 hours ago [-]
Plus the PDF file name extension has been co-opted as a censorship-safe shorthand for Donald Trump and the Epstein Class he's protecting. Adobe must be totally pissed off about that.
You're right, PDFs are horrible scary monsters who you should never trust.
cowlevel 2 days ago [-]
PDFs are usually untrusted input and C provides no assurance there isn't a bug in the code that allows corrupted input to turn into arbitrary remote code execution.
F3nd0 2 days ago [-]
Other than Ada/SPARK, which languages can guarantee this won’t happen?
tialaramex 2 days ago [-]
This trivially can't happen in WUFFS. Forget RCE, WUFFS can't even do a traditional Hello World program because (1) you can't do I/O in WUFFS and (2) the language doesn't have strings.
Very few languages can prevent you writing something like "if(text == "shibboleth") rootshell();" but most languages don't make it trivial to write accidentally.
mahemm 18 hours ago [-]
Pretty much any memory managed language? Java, Go, Rust, Python, pretty much anything other than C/C++ these days is memory safe for security purposes.
F3nd0 4 hours ago [-]
Even C and C++ can be memory-safe if you need them to [1], but is arbitrary code execution strictly about memory safety only?
[1] https://fil-c.org/
recursive 2 days ago [-]
buffer overflow vulnerability in code dealing with user generated data and a complex file format.
Also, I get that a lot of sensitive information is exchanged with PDFs these days, but why should PDFs have encryption built-in to the file format? Sensitive information is also exchanged in image files, word documents, zip files, html, etc etc etc etc. If you take all the work that goes into making the crypto UX decent for one kind of file and apply that to "all files", then each ecosystem doesn't have to invent their own.
This is just like "high-end" car manufacturers insisting on making their own software, and not integrating apple carplay. They're either going to make a truly shitty podcast app, or they're not even going to bother and instead tell people to use bluetooth to listen to podcasts like it's 2006.
Because very few 'end user' people know how to use en/decryption. So it's much easier to send them a familiar file and say 'enter this password' than to have them searching the web to work out which arguments to pass to openssl. In a command line? What's that?
I received an AES-encrypted file recently but neither gnupg nor openssl could determine what mode and keysettings the sender had used, so it was just a useless lump of data. Very secure though...
Since the kind of data people want available may differ for each file format, here we are.
So you could open encrypted documents on iOS and Android.
Another pet peeve is when people use the rand() when they want hash() but I will leave that rant for another day.
They are so close that people can and often do build rand() as "internal state s = hash(s) return s" (or similar). then other people, wanting that deterministic hash() behavior thus accidentally exposed, build entire worlds(literally) out of rand().
Another problem with this is that the rand() internals are opaque and unknown and can change without violating the spec. hash(), because it is supposed to be deterministic, usually has an exposed stable algorithm.
A specific example. At one job I found they were storing long term customer order archives encrypted where the key was a hash of the date, this in itself is a little suspicious but the archives were offline and physically locked up on site, so not too bad. The real wtf was that the encryption was done on a win98 machine with a perl script that was basically "seed(date); key = rand(); encrypt(data, key)". expecting to regenerate the key if they ever wanted to look at the data. When I saw that I went "I don't know much about perl, but that does not feel stable" and did a few checks. Sure enough the behavior of rand() could change depending on the operating system or even version. making the keys highly dependent on that exact win98 machine with that exact version of perl, I think they ended up using that machine to generate and store all used keys in a database so other machines could decrypt the archives.
Each with varying degrees of trust. The outcome is never perfect, but that’s not their purpose.
Every hiring manager worth their salt has caught at least one completely incompetent applicant with a CV full of certifications.
The human bar is not that high.
I would much rather have rigorous testing than a filter based on the origin of the code.
For AI this will be impossible, however.
If you're talking about testing of code, well "tests can only prove the presence of bugs, not their absence"
Would the new LLM model owners like to strike this down, or use it to demonstrate how dangerous unrestricted models can be?
always Base64Encode/Decode!
Rule #2? Please don’t.
man encrypt works. info /encrypt works too.
And if you're a sysadmin, be extremely careful when generating keys in VMs or embedded devices. They tend to overestimate their entropy sources - it's possible that every clone of a VM generates the same keys. In some cases (cough ECDSA) generating the same key and nonce to sign two different messages is catastrophic - it immediately leaks the private key.
-object rng-random,id=objrng0,filename=/dev/null
or maybe just a file that contains 4 :O
btw... im sure there's some legacy rng in windows or some shit that isnt good. read the docs but if it's the blessed system rng, you're probably fine!
although... i suppose if this is news to you (the person reading this), then you probably shouldn't be implementing whatever you are that really requires prng. ask a friend for help. im not trying to be a jerk, i just want to make sure you dont hurt yourself!
Rule 3b: Failing rule 3, disclose motivations and full list of employers and / or customers
It makes me wonder: Coincidence, really? There's enough there to think that there might be some invisible hand behind it.
You're confusing just assuming by default its enough for purpose rather than not caring at all.
You can downvote anything not interesting.
If he have list some alternative or give example, it might be interesting.
Same thing applies here. Even Rust has a crate for dealing with binary data, despite its memory promises: https://crates.io/crates/untrusted
It's a fucking minefield, and this is one area where the Rust zealots are undeniably correct. It doesn't have to be Rust, any memory safe language will do, but Rust also happens to be performance competitive and that's usually also desirable.
Rust is a general purpose programming language, which is great if your problem might be something never imagined before, but this literally isn't our first rodeo, we have wrangled lots of file formats before, we should use a language purpose-built to do that safely.
I don't understand how I hit the anti-Rust tripwire here:
> My comment: any memory safe language will do
I like 4th edition D&D but if you're trying to make a story about nuanced inter-personal conflict in which there's no actual violence it's just not the right roleplaying system and so I'm not going to agree with your choice to recommend 4eD&D as the system for the story "Love and Jealousy in the Elven Forest"
I've written a whole bunch of Rust, and hardly any WUFFS - but, I wasn't writing code for Wrangling Untrusted File Formats and that's very much what you're doing in a PDF parser.
You're right, PDFs are horrible scary monsters who you should never trust.
https://github.com/google/wuffs