4 ms·

RSA relies on large primes for the private/public key generation. The random functions in browsers aren't designed to make numbers like it, and are probably bas

by nwh 14y ago

RSA relies on large primes for the private/public key generation. The random functions in browsers aren't designed to make numbers like it, and are probably based on algorithms like the mersenne twister, which are fast but very predictable. So much so that based on a number of samples, the pseudo-random number generators in common languages can be guessed with very high accuracy. It's essentially bad because the generated secret keys are predicable, to the point where a single CPU could crack them in minutes, which is obviously undesirable.

onli 14y ago
I don't see how such an attack would be possible on a piece of software which does RSA-key-generation and is seeding the random-number-generator with input from the user. How would you get multiple samples? You wouldn't get any sample at all, apart from maybe the public-key (probably not even that). To do such an attack based on the pseudo-random-number-generator, someone on the outside of the key-generation-process would need to be able to guess the prime-numbers used on a specific account just by the predictability of the rng. How should that work? Again, if having the choice, I will always use the conservative option when dealing with crypto-stuff (using an approved crypto-library). And really: Not saying what you say is wrong. Just don't see the attack-vector here. Would you like to give me a hint?
- nwh 14y ago
  I'm not entirely sure how the Mega entropy gathering system works, but I can take a guess. Through the sign up process try ask for users to both enter information with the keyboard, and click buttons with the mouse. There's not a whole lot of randomness in either action, and relying on it too much could start to reveal things about the user in the encryption key generated. For this, lets assume I can predict the random numbers with minimal computation. That's realistic. PHP session variables can have their random seed extracted in a very short time frame using similar methods (<30 minutes). They would first be relying on the randomness of the path that users take with their mouse between buttons. That's unfortunately fairly predictable, most of the users will click on the buttons in the same order, and probably take reasonably similar paths to get there. If we could work out the probabilities, the key search could be focused on the most likely path a user might take. So we move on to keystrokes. There's not a whole lot of variation there either. If we use the keystrokes themselves, we might begin to reveal personal information in the key. I'm sure you wouldn't want your password baked into the keys you are relying on to protect your freedom / anonymity. The length of keystroke is what they would use, how much time the button stays down and the distance in time between keystrokes. There's some randomness there, but I wager that most people type with the same sort of characteristics. If they're on a touch screen device like an iPhone, you get no real timing information except for delay between letters. There's no denying that it is still brute force and very unlikely, but using attacks like that could be the difference between decades of computation and hours

by nwh 14y ago

onli 14y ago

I don't see how such an attack would be possible on a piece of software which does RSA-key-generation and is seeding the random-number-generator with input from the user. How would you get multiple samples? You wouldn't get any sample at all, apart from maybe the public-key (probably not even that). To do such an attack based on the pseudo-random-number-generator, someone on the outside of the key-generation-process would need to be able to guess the prime-numbers used on a specific account just by the predictability of the rng. How should that work? Again, if having the choice, I will always use the conservative option when dealing with crypto-stuff (using an approved crypto-library). And really: Not saying what you say is wrong. Just don't see the attack-vector here. Would you like to give me a hint?

nwh 14y ago
I'm not entirely sure how the Mega entropy gathering system works, but I can take a guess. Through the sign up process try ask for users to both enter information with the keyboard, and click buttons with the mouse. There's not a whole lot of randomness in either action, and relying on it too much could start to reveal things about the user in the encryption key generated. For this, lets assume I can predict the random numbers with minimal computation. That's realistic. PHP session variables can have their random seed extracted in a very short time frame using similar methods (<30 minutes). They would first be relying on the randomness of the path that users take with their mouse between buttons. That's unfortunately fairly predictable, most of the users will click on the buttons in the same order, and probably take reasonably similar paths to get there. If we could work out the probabilities, the key search could be focused on the most likely path a user might take. So we move on to keystrokes. There's not a whole lot of variation there either. If we use the keystrokes themselves, we might begin to reveal personal information in the key. I'm sure you wouldn't want your password baked into the keys you are relying on to protect your freedom / anonymity. The length of keystroke is what they would use, how much time the button stays down and the distance in time between keystrokes. There's some randomness there, but I wager that most people type with the same sort of characteristics. If they're on a touch screen device like an iPhone, you get no real timing information except for delay between letters. There's no denying that it is still brute force and very unlikely, but using attacks like that could be the difference between decades of computation and hours