Tag Info

No. The challenge for RSA-155 (which is 512 bits) was broken in 1999. This took 6 months on pretty advanced hardware to break at the time, which works out to 8000 MIPS years. It should be much less today. FYI, RSA 768 took just under 3 years.

As fgrieu notes, the problem as specified is unsolvable: if the server alone should not be able to decrypt the files, then there must be something (in this case, the password) possessed by the user but not the server which is needed to decrypt them. If the user loses this extra information, there's no way the server can provide them access to the files ...

It's impossible to say what the device really does; there are so many possible ways. If you don't find any technical specification describing it, I would be wary of the actual security of the device. If the device is FIPS 140 approved at any level, you can find back the FIPS certificate and the relevant security policy on this NIST web page.

I prefer a ~128 bit security level. With ECC this means a curve with ~256 bits, with DH or RSA this corresponds to around 3000 bits. If you can accept a lower security level, the advantage of ECC over DH/RSA gets smaller. My favourite is Curve25519, which has easily available high performance implementations. An alternative is P256 which is a NIST standard, ...

I don't have any experience with this myself, but Tom Ritter talked about this on twitter: Matthew Green: Out of curiosity: do you happen to know offhand how much it costs to factor a 512-bit RSA key on EC2? Tom Ritter: My personal costs are \$120-\$150 with my setup. You can probably do it cheaper, heard reports of \$75. He also published a ...

Short answer: the problem you're trying to solve can't be fully satisfactorily solved. With the assumption that an adversary control your system to the point of being able to read the RAM containing secret keys, you won't be able to define a secure system. The closest thing to a real practical solution is to bring in a trusted execution environment. HSMs ...

The answer to the question: Is there any way to store private keys that are encrypted with a users clear text password and still have a way when resetting a password to preserve access to the users data is actually yes. Simply store two copies of each private key - one encrypted with the user's password and one encrypted with the administrator's public ...

Considering special purpose hardware, according to [40] sieving for a 1024-bit RSA modulus can be done in a year for about US \$10,000,000, plus a one-time development cost of about US \$20,000,000, and with a comparable time and cost for the matrix. -- Bos et al. RSA.816 offers very short-term protection against small organizations Should not be ...

I do not know what the practice is, much less what your particular device do, but I can tell what could be done. The token could contain a secure Micro-Controller Unit, complete with CPU(s), RAM, Non-Volatile Memory (EEPROM or Flash), crypto accelerators for symmetric and asymmetric crypto, and a communication interface (USB, or perhaps ISO-IEC 7816-3 with ...

It is not correct. Actually, your usage of RSA is entirely wrong. In a public key scheme, there are 2 keys, one for encryption and one for decryption. If you use the private key to encrypt.... the public key would be used to decrypt. That means everyone can decrypt, as the public key is public. If you use a public key scheme and the private key to create ...