# Tag Info

18

This question has many problems in the way it was asked, and clearly did not come after doing some investigation. However, since this seems to be a misconception that is spreading widely, I will relate to it. It is not true that the "crypto community" (whoever that is) believes that the NSA can break RSA. In fact, if Snowden taught us anything, it is that ...

10

There are many different cryptography laws in different nations. Some countries prohibit export of cryptography software and/or encryption algorithms or cryptoanalysis methods. In some countries a license is required to use encryption software, and a few countries ban citizens from encrypting their internet communication. Some countries require decryption ...

9

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 ...

8

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 ...

7

SafeCurves lists some ways to compare the security of elliptic curves. Their security criteria are split to "ECDLP security" and "ECC security". Failing the former basically means "there is no way to use this curve securely in general" while the latter "it is difficult to implement this curve securely". None of the (few) BouncyCastle-supported curves that ...

7

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

Yes, it can be decrypted easily because it will use DES (CBC) mode of operation. DES only has an effective key size of 56 bits. So the key and the can be brute forced regardless of the (PBKDF1) key derivation. MD5, while considered broken by itself, is less of an issue when it is used within PBKDF1 - as long as the password contains enough entropy of course....

5

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 ...

5

This answer has been updated a lot, again, after being accepted. I now base my analysis on simple functional equivalent source code to the deterministic PRNG used. The cryptosystem proposed works, in the sense that it allows decryption. The best cryptanalytic method there is to predict further output is enumerating the 64-bit key by brute force. That's in ...

5

Assuming this generator is well-seeded, you probably can't learn much about the next output. You observe two outputs, so 32 bits in total. The state of the generator is 48 bits. Thus, there will probably be about $2^{16}$ states of the generator that are compatible with your two observations. This means that most of the 16-bit values for the next output ...

5

With pure asymmetric encryption there is no way to ensure integrity and authenticity, since anyone who knows your public key can encrypt any message for you. For that you would need either a symmetric key to use for a MAC (in which case you could use it/derivatives for symmetric encryption too) or a signature from the sender. And in the latter case the ...

4

For simple XOR-based encryption algorithms such as OTP, the key size must be the same as the message size. If you choose a smaller key and try to divide the message into chunks, you would not have a perfectly secure scheme anymore. Now, since you tagged java, I'm assuming that this increase in time for smaller key sizes is due to the code trying to divide ...

4

When using ElGamal on elliptic curves you have two possibilities: Encoding free Version of El Gamal Use a version of ElGamal such as "hashed ElGamal" that avoids the task of mapping messages to points on the curve. In standard ElGamal on elliptic curves you would compute the ciphertext as $(C_1,C_2)=(kP,M+kY)$ where $k$ is a random integer, $M$ the ...

4

If I were to guess on what might be wrong on code I haven't seen, well, with SHA256, you stir in a per-round constant. Maybe the constant you have for round 24 (which should be 0x983e5152 if you count rounds from 0) is wrong...

4

Well, if $g$ is a generator of $\bmod\ p$ for prime $p$; that is, if all values in the range $[1, p-1]$ are possible values for $g^i \bmod p$, then we have $g^a \neq 1 \bmod p$ for any $a = (p-1)/r$ where $r$ is a prime factor of $p-1$. You select $p$ to be a "safe prime", that is $p-1 = 2 \times q$ where $q$ is also a prime. This implies that, in this ...

4

One way to do this, if you're working with a multiplicative group $Z^*_p$, is to pick a prime $p$ so that $p-1$ has a large prime factor $q$; once you have this, then to generate a generator of order $q$, you pick a random value $h$, compute $g = h^{(p-1)/q}$, and if that is not 1, then $g$ is a generator of your group. Obvious questions: How do you find ...

4

There are several obvious ways to optimize the search. The easiest approach would be to take advantage of the identity $g^e \cdot g = g^{e+1}$. That is, if we have already computed $g^e$, and verified that it is not the value we're looking for, then to step to $g^{e+1}$, we don't compute $g^{e+1}$ from scratch; instead, we take the $g^e$ value we have, and ...

3

Your javascript library linked to has no restrictions on key size. Many libraries out there that implement RSA will have a restriction on the key size. This is to make sure developers are following best practices as if the key size is too small, the security of the cipher is completely blown. It looks like the Java library you are using won't let you use key ...

3

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 ...

3

The key thing here is that even in the case that the final algorithm used is "SHA1PRNG", some entropy will be collected somehow for generating the seed that initializes the PRNG. So, it all depends on the seed. In this case, you can see in the code of sun.security.provider.SecureRandom that the seed is generated by the class sun.security.provider....

3

"RSA/ECB/PKCS1Padding" - as you already found out - is not really implementing ECB. For instance Bouncy Castle also has "RSA/None/PKCS1Padding" to mean the same thing. ECB is used for block cipher modes of operation, and RSA is not a block cipher. For block ciphers ECB makes some kind of sense; it basically means performing the block cipher operation for ...

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 ...

2

PLEASE NOTE: The code I link to below has not yet been reviewed by anyone with professional cryptography experience. I expect that it contains bugs, and it is definitely not production-ready. I am still learning about the JCA; there are parts of the code I have not finished, and there are parts that I will most likely go back and redo. That said, the tests ...

2

There are other ways to "win" space. $\:$ Also, see this answer regarding compression. You can remove (or just reduce the size of) the IV, since if the salts are different then the derived keys should be sufficiently independent. You can make the salt smaller than what it should be if bandwidth wasn't an issue. Additionally, the salt length can depend on ...

2

First, using only a single SHA512 to hash the password is not enough. You should use something like bcrypt with a long salt to store user password "hashes". A simple SHA512 can be attacked quite powerful with a dictionary attack, just trying millions of possible passwords and calculating the SHA512 hash for that until one matches. Concerning the encryption ...

2

You may probably use any curve you like, depending on your special requirements (environment, computational aspects, ...) and the curves implemented by your library (see otus answer refering to some concrete security findings related to specific elliptic curves, and how sensible they are to certain attacks). The reason why the curves are pre-computed, is ...

2

Nitpick: keytool accepts both alias and keypass if specified; if not specified it prompts for key password if needed but defaults alias to mykey. A JCEKS file can be operated on either by keytool or by other code. JCEKS can support three types of entries: privateKey, trustedCert, and secretKey (the older and default JKS file can do the first two). The ...

2

Assuming that nobody's screwed up the implementation, it should not matter what kind of RNG you get. This is because all java.security.SecureRandom implementations are supposed to be cryptographically strong, as defined in RFC 1750 §6.3 (emphasis mine): 6.3 Cryptographically Strong Sequences In cases where a series of random quantities must be ...

2

Maarten appears to make it look like it's an impossible (or, at least, an exceedingly difficult task) to recover the two plaintexts. Indeed, if you literally know nothing about the plaintexts, it can be difficult. However, you typically have a reason you are interested in the messages, and hence often have a clue as to what language they might be. If the ...

2

Assumption: you've saved the RSA public key using the default encoding in Java (for the SUNRSA provider), as in: KeyPairGenerator kgen = KeyPairGenerator.getInstance("RSA"); kgen.initialize(1024); KeyPair kp = kgen.generateKeyPair(); Files.write(new File("Public.key").toPath(), kp.getPublic().getEncoded()); This generates an X.509 ASN.1 ...

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