• towerful@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    11 hours ago

    My experience of checksums are in things like serial where they can potentially recover a corrupt bit.
    I presume in the case of encryption, a checksum is more of a hash of the raw data? Like a one-way deterministic compute. Easy to get a hash of data, extremely difficult to get data from a hash.
    In which case, it’s fine. Passwords are hashed (granted, multiple times), but a cryptographically secure hash is not to be underestimated.

    • Pika@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      6
      ·
      edit-2
      10 hours ago

      You are correct, my concern with it isn’t retrieving the data however, its the possibility that if the person involved had the means to, they could have a table of check-sums of files of interest. This system could be used to confirm or deny a file of interest is present on the device.

      For the everyday person this is a non-issue, but from a privacy POV you should not be able to get any information in regards to what a file is.

      Rainbow tables for password cracking works off a similar system, they take a bunch of commonly used passwords, hash them and compare them to leaked databases. If the hash matches an account you have the password. Most password handlers get around this by salting it, and hashing it repeatedly X amount of times, but I doubt that apple would do that for a checksum(and regardless they would know X and how it was made).

      Again though I acknowledge that it’s a paranoia level concern, but I still am firm that a true encryption solution should not be able to get any type of info out of it that may help the third party.