The case of the 9 bit AES key

(v12.sh)

59 points | by ledoge 2 hours ago

9 comments

  • jburgess777 6 minutes ago
    Does the DMCA still make it illegal to access encrypted content no matter how easy it is to discover the key? https://www.law.cornell.edu/uscode/text/17/1201

    Would the new LLM model owners like to strike this down, or use it to demonstrate how dangerous unrestricted models can be?

  • tptacek 1 hour 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.
  • ubutler 1 hour ago
    Rule #1 of rolling your own RNG: don’t.

    Rule #2? Please don’t.

    • ahartmetz 13 minutes 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

    • j16sdiz 1 hour ago
      That's why we use the system RNG !
      • cowlevel 32 minutes 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.

      • flanz_10 50 minutes 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!

  • NelsonMinar 38 minutes 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 10 minutes 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.
    • LeoPanthera 36 minutes 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.

    • rsalus 34 minutes ago
      I think it's safe to assume anything associated with PDFs is radioactive.
    • HackerThemAll 35 minutes 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 12 minutes 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.
      • gsich 34 minutes ago
        one and the same
  • esafak 33 minutes ago
    I assume this is the fruit of AI-driven decompilation? Nice work.
  • JonChesterfield 1 hour ago
    Wonderful.
  • RobotToaster 34 minutes ago
    Obligatory xkcd https://m.xkcd.com/221/
  • paulpauper 2 hours ago
    it's like the weak hardware wallet entropy bug
  • jeffbee 1 hour ago
    You'd have to be completely off your rocker to use a PDF tool written in C anyway.
    • advisedwang 1 hour ago
      very VERY few people judge tools like this by the language used to develop them.
      • jeffbee 1 hour ago
        How many people judge their tools based on the AES key entropy?
        • OptionX 1 hour ago
          A lot actually.

          You're confusing just assuming by default its enough for purpose rather than not caring at all.

      • j16sdiz 1 hour 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 1 hour ago
      What are the alternatives?
      • crote 1 hour ago
        PDF.js, for example. It's what Firefox uses, and most websites with integrated on-page PDF viewing functionality.
    • lirolero 1 hour ago
      Genuine question, since I'm not very knowledgeable about this: why is using C for a PDF tool such a bad idea?
      • tptacek 1 hour 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.
      • zamalek 25 minutes 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.

      • cowlevel 31 minutes 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.
      • recursive 1 hour ago
        buffer overflow vulnerability in code dealing with user generated data and a complex file format.