Keyoxide: aspe:keyoxide.org:KI5WYVI3WGWSIGMOKOOOGF4JAE (think PGP key but modern and easier to use)

  • 1 Post
  • 69 Comments
Joined 2 years ago
cake
Cake day: June 18th, 2023

help-circle
  • Amusingly, in a way, we are using microphotography (photolithography) to produce images on the scale of hundreds of atoms. Then we stack those images to achieve dense structures of data that can be read out electronically (flash chips).
    Making a rom chip using this technology would be a lot like that encyclopedia britannica in a matchbox, except more around the size of a grain of dust. Of course we tend to make ram instead, where information is only encoded after the photolithography is done creating the structure.











  • Was about to say this.

    I saw a small-time project using hashed phone numbers and emails a while ago, where assume stupidity instead of malice was a viable explanation.

    In this case however, Plex is large enough and has to care about securiry enough that they either
    did this on purpose to make it sound better, as a marketing move,
    did not show this to their security experts,
    or chose to ignore concerns by those experts and likely others (turning it into the first option basically)

    There is no option where someone did not either knowingly do or provoke this.


  • It isn’t usually. If it was, the server-side function wouldn’t need a constant runtime at different-length inputs since the inputs would not have differing lengths.

    The problem with client-side hashing is that it is very slow (client-side code is javascript (for the forseeable future unless compatibility is sacrificed)), unpredictable (many different browsers with differing feature-sets and bugs), and timing-based attacks could also be performed in the client by say a compromised browser-addon.

    For transit a lot of packaging steps will round off transfer-sizes anyhow, you typically generate constant physical activity up to around 1kB. Ethernet MTU sits at ~1500 bytes for example, so a packet of 200 bytes with a 64 char password or a packet of 1400 bytes with a 1024 char password containing some emoji will time exactly identically in your local network.


  • You can easily get the hash of whole files, there is no input size constraint with most hashing functions.
    Special password hashing implementations do have a limit to guarantee constant runtime, as there the algorithm always takes as long as the worst-case longest input. The standard modern password hashing function (bcrypt) only considers the first 72 characters for that reason, though that cutoff is arbitrary and could easily be increased, and in some implementations is. Having differences past the 72nd character makes passwords receive the same hash there, so you could arbitrarily change the password on every login until the page updates their hashes to a longer password hashing function, at which point the password used at next login after the change will be locked in.