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

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

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

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

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

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

3

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

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

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

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

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

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

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

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

1

Simply put, you need to first understand why that code is bad. You also need to know what preimage resistance is. The comments tell you the algorithm, you don't even need to read the code. // Pad the String with spaces so that it is a multiple of 4 characters // XOR each consecutive 4 byte block This is not cryptographically secure, or even secure from a ...

1

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

1

Ed25519 is a specific implementation of EdDSA using the Twisted Edwards curve: x^2 + y^2 = 1 + (121665/121666) * (x^2)(y^2) It's known as high speed high security signature algorithm. For using the code you pointed out, you need to feed sk, pk, m, sm. So first you need to call publickey function with sk, then call signature function with m, sk and pk. PK ...

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

1

It's probably the generation of the IV that takes the time, not the 3DES encryption. 3DES encryption itself should indeed at least scale with the size of the plaintext.

1

One option is that your benchmarking code isn't exact enough to show the small differences. With long enough inputs the time should scale linearly with the number of 64-bit blocks. However, with small inputs, like your 1 vs. 125 blocks, it is possible to see the symptoms you describe – scaling decryption time, but approximately constant encryption time. You ...

1

This is both a DES (or any block cipher) and a programming concern. It is not a problem, just something to be aware of. The reason time/character decreases with larger plaintexts is that the initial overhead and memory management takes up the bulk of time with small inputs. With large inputs (megabytes+) the time/char will stabilize to a fairly consistent ...

1

I second the suggestion of a strong password based KDF, e.g. PBKDF2 or scrypt, which you use to derive the encryption key(s) from the user's password. Additionally, use authenticated encryption (e.g. either AES GCM or AES CTR + HMAC). If you can't open the encryption using the key derived from the password they enter, you know the password was wrong. No ...

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