"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.
replyRule #1 of rolling your own RNG: don’t.
replyRule #2? Please don’t.
That's why we use the system RNG !
replyWonderful.
replyit's like the weak hardware wallet entropy bug
replyYou'd have to be completely off your rocker to use a PDF tool written in C anyway.
replyvery VERY few people judge tools like this by the language used to develop them.
replyjust down vote it.
replyYou can downvote anything not interesting.
If he have list some alternative or give example, it might be interesting.
How many people judge their tools based on the AES key entropy?
replyA lot actually.
replyYou're confusing just assuming by default its enough for purpose rather than not caring at all.
What are the alternatives?
replyPDF.js, for example. It's what Firefox uses, and most websites with integrated on-page PDF viewing functionality.
replyGenuine question, since I'm not very knowledgeable about this: why is using C for a PDF tool such a bad idea?
replyI 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.
replybuffer overflow vulnerability in code dealing with user generated data and a complex file format.
reply