# Tag Info

8

It looks like there are really two potential problems. From the mailing list all private keys generated on Android phones/tablets are weak and some signatures have been observed to have colliding R values, allowing the private key to be solved and money to be stolen. Recall that with bitcoin Transactions are cryptographically signed records ...

6

Hash algorithm strength is important, but it is not so important in key derivation functions. It is unlikely that even if SHA-1 is broken that it would influence the security of PBKDF2. You are better off using SHA-1, and increase the iteration count up to a level that is tweaked for your specific configuration. If you must, you could use Bouncy Castle to ...

6

An attack would be trivial if the seed of the RNG was only 32 bits; just enumerate the seeds, and test which matches the intercepted messages. That's easy. However the default Java Random class uses a 48-bit state and seed (which would still be attackable, though $2^{16}$ times less easily), and there are safe subclasses, thus use of Random does not imply ...

4

No, this is not a safe implementation; from the modulus and the public exponent, it would be possible to factor the modulus. The reason is that you pick the private exponent to be small; one-fifth the size as the modulus. It's known that knowledge of a public exponent corresponding to that is sufficient to factor. The obvious question is "why are you ...

2

As long as you ensure that $n_1\leq n_2$ is guaranteed, the value $r^em\pmod {n_1}$ can be treated as an element in $Z_{n_2}$ and the "outer blinding" and "outer unlinding" in $Z_{n_2}$ does not change this value. Consequently, if you compute the "inner unblinding" in $Z_{n_1}$ after the "outer unblinding" your proposal works. Remarks from the previous ...

2

ECB, CBC and such cipher modes are something that relate to symmetric cryptography. In context of RSA, it is important to study from documentation of the product what they mean as they do not ordinarily apply. Based on the articles you provide, this statement is correct: The mode, ECB in this case, is ignored for RSA.Use PKCSPadding. The max amount of ...

2

To begin with, let's assume that the attacker cannot extract the AES key from your software. That means the best they can do is a chosen-plaintext attack on AES: choose a block $Y$, request its encryption $Z$, repeat as many times as desired and try to use the results to figure out something useful about the encryption of other plaintext blocks. Since AES ...

1

embedding a symmetrical (AES) key in your software really is pointless - an attacker could easily extract the key and generate their own software license key, or worse, create a small program (a crack) that allows other users to generate their own license keys I recommend RSA - generate 'Z' (as per your question) by signing the data 'Y' with a private key, ...

Only top voted, non community-wiki answers of a minimum length are eligible