3 ms·

It's easy to see that {process-id, parent-id, timestamp} can lead to a pretty predictable random number seed. But Amazon also had another easily available sour

by mdda 15y ago

It's easy to see that {process-id, parent-id, timestamp} can lead to a pretty predictable random number seed. But Amazon also had another easily available source of randomness : the timestamps of other customer's orders. Why not generate a random #, and index to a random customer, and re-seed? One extra DB lookup and you've got a whole lot more randomness (like a private lava-lamp) to access.

bdonlan 15y ago
Both sides have to generate secure random numbers in order to perform an ephemeral diffie-helmann exchange securely; if the client's random number is insecure, a man in the middle attack becomes possible. Non-DH-based exchanges are even worse - the entire exchange hinges on a random number generated by the _client_. The server effectively doesn't even have a chance to generate a random number at all.
- deleted 15y ago
  [deleted]
- mdda 15y ago
  But surely the client could use human input as it's source of randomness too : After all, in this case (browser purchases) the user is going to be hitting keys and/or moving the mouse.
  - ars 15y ago
    It could, and today it does. But back then it didn't.
shabble 15y ago
Using a physical process is generally going to be harder to exploit than a software one. There's going to be the possibility of uneven distribution (customer order timestamps may cluster at certain parts of the day, rather than being evenly distributed), as well as the (granted, small) possibility that on some small site without Amazon scale, the attacker can generate enough entries that it can reasonably assume one of them will be picked by the random index. One interesting story about exploiting a poor RNG in Online Poker: http://www.cigital.com/papers/download/developer_gambling.php http://www.cigital.com/papers/download/developer_gambling.ph... https://webcache.googleusercontent.com/search?q=cache:AdC18Y8C6UkJ:taeb-blog.sartak.org/2009/03/predicting-and-controlling-nethacks.html https://webcache.googleusercontent.com/search?q=cache:AdC18Y... is another one, where the PRNG seed for a shared Nethack server wasn't random enough, and could be discovered and synchronised for fun and cheaty profit.

by mdda 15y ago

bdonlan 15y ago

Both sides have to generate secure random numbers in order to perform an ephemeral diffie-helmann exchange securely; if the client's random number is insecure, a man in the middle attack becomes possible. Non-DH-based exchanges are even worse - the entire exchange hinges on a random number generated by the _client_. The server effectively doesn't even have a chance to generate a random number at all.

deleted 15y ago
[deleted]
mdda 15y ago
But surely the client could use human input as it's source of randomness too : After all, in this case (browser purchases) the user is going to be hitting keys and/or moving the mouse.
- ars 15y ago
  It could, and today it does. But back then it didn't.

shabble 15y ago

Using a physical process is generally going to be harder to exploit than a software one. There's going to be the possibility of uneven distribution (customer order timestamps may cluster at certain parts of the day, rather than being evenly distributed), as well as the (granted, small) possibility that on some small site without Amazon scale, the attacker can generate enough entries that it can reasonably assume one of them will be picked by the random index. One interesting story about exploiting a poor RNG in Online Poker: http://www.cigital.com/papers/download/developer_gambling.php http://www.cigital.com/papers/download/developer_gambling.ph... https://webcache.googleusercontent.com/search?q=cache:AdC18Y8C6UkJ:taeb-blog.sartak.org/2009/03/predicting-and-controlling-nethacks.html https://webcache.googleusercontent.com/search?q=cache:AdC18Y... is another one, where the PRNG seed for a shared Nethack server wasn't random enough, and could be discovered and synchronised for fun and cheaty profit.