# Tag Info

0

Is it necessarily a peer review process? Does an algorithm need to withstand exploit attempts for N amount of time by M many experts? Or, is there a mathematical proving process that security experts can apply on their own to evaluate an algorithm? Yes, yes, and sometimes. Some algorithms can be proved secure under certain assumptions. However, ...

0

I'll show a scheme with the following presumption: the game has its own server key, this key is hidden in the game data somewhere (this usually cannot be secured completely, the game has to store the key somewhere); So what you can do is to encrypt your game data with a randomly generated data key. If you use GCM mode of operation then you can verify if ...

1

GPG is an implementation of OpenPGP, which is a higher level protocol than e.g. mcrypt. So use GPG for PGP compatibility and mcrypt or related libraries for more direct - lower level - access to algorithms. AES is Rijndael for a block size of 128 bits and the 128, 192 or 256 bit key sizes. So you are OK there. Learn about modes of operation and something ...

1

There are good reasons to think an algorithm being in Suite B is evidence NSA thinks it's secure (they are used to protect classified materials). There are also reasons to think algorithms they recommend for others may not be (it's happened before). So I don't think you can objectively say much about an algorithm either way just on the basis of whether it's ...

4

It mainly depends on how the algorithm was selected. If it was selected by a public competition like for AES, then it is likely to be secure. If it was forced in by the NSA such as Dual-EC random number generator, then you may have some doubts. Other questions you may want to ask yourself are: Is this an "original" algorithm or was the problem that it ...

0

No, it's not correct. When large bit-wise operations are used in cryptography, they are normally decomposed into byte[], not int32[]. Prime-modulus PK operations are done with large number libraries, on 2048 bits, so again, there is no real advantage to a 64 bit architecture over a 32 bit architecture. Further, the problem with encryption was never speed. ...

5

Saying that the large numbers you can handle with 64 bits allow for better encryption is misleading. 64 bits is too short for modern cryptographic algorithms. Those algorithms which do rely on large numbers, need numbers much larger than 64 bits. For those, the computation have to be split up and processed in smaller parts. But being able to process 64 bits ...

9

In terms of marketing hype, that statement rates about a 9 in a scale from 0-10. The reason is that we don't choose the encryption algorithm based on how many bits the CPU can handle at once. Instead, we choose a secure algorithm, and then implement it using the resources that the CPU provides us. There aren't any algorithms we cannot implement on a 32 ...

2

In the case of RSA, the key element is modular exponentiation. Modular means that you are doing all computations modulo a given integer n: whenever you add, subtract, or multiply integers together, you then do a division of the result by n, and you keep only the remainder. For instance, if you multiply 8 with 11 modulo 15, you first get 8×11 = 88, and 88 ...

2

Symmetric encryption works with a single key because the function that is used to encrypt/decrypt is symmetric: f(f(x)) = x. In asymmetric encryption, you have two functions that inverse each other (called inverse functions). You get security only from the fact that only one of these functions is public, and the other one is hidden. To make it more ...

1

One way to look at public / private key-pairs is to view it as yin and yang. The yin can encrypt things that only the yang can decrypt. At the same time The yang can encrypt things that only the yin can decrypt. This is used by public key cryptography We publish our public keys. We keep our private keys private. We can send messages that only the ...

2

Small addition: You do not lose integrity when using encrypt-then-MAC. Since encryption is an injection, distinct plaintexts produce distinct ciphertexts, so plaintext forgery implies ciphertext forgery, which is hard if encrypt-then-MAC is secure.

0

As bmm6o wrote in the comments, all encryption is meant to be reversible only when you know the correct key. In the case of symmetric encryption it's the secret key which was used to encrypt the message. In the case of asymmetric encryption it's the private key that corresponds to the public key which was used to encrypt the message. Hashing is not ...

6

Using a MAC on the plaintext may potentially leak information about the plaintext (MAC algorithms do not necessarily ensure confidentiality of the data they are applied to, although some MAC algorithms like HMAC seem pretty safe). If you want to avoid this (theoretical) problem, then you should encrypt the MAC on the plaintext (i.e. MAC-then-encrypt, not ...

1

There is some confusion in your question, because a signature in a public key cryptosystem is (usually) not just a hash, but a hash of the message that is signed using the private key. E.g. in RSA it would be a hash value padded and raised to the private exponent. There are two ways to have an authenticated encryption in a public key system: Should we ...

4

As long as you're using any modern encryption algorithm (and you're using it correctly: random key, new random or unique IVs for each message, depending on the mode of operation, etc.) then you'll be fine. In fact, you'd be fine even if an attacker got to choose which plaintext you encrypted and got to see the result; this information would not help him ...

6

OpenPGP as defined by RFC 4880 knows two different encodings. Binary encoding Obviously, there is no reasonable limitation to an (ASCII) character subset in binary encoding. Radix 64 Radix 64 is also often entitled ASCII armored. In the end, it is a base64 encoding with a checksum. The content may consist of [a-zA-Y0-0+/=]. ASCII-armored OpenPGP ...

4

You can get what you want programmatically. No special ciphers or modes needed. You say there is a single, continuous subset that needs to be encrypted. Thus, you could have a function where the programmer specifies the start of the portion of the plaintext that needs to be encrypted and the number of bytes to encrypt. The function could pull that part out, ...

1

As block ciphers are invertible, and since XOR is too - the main operation on the key stream for many stream ciphers - the resulting encryption/decryption modes of operation are often invertible. For stream ciphers that create a key stream that is XOR'ed with the plaintext, it is even true that $E = E^{-1}$. Some block cipher modes of operation however ...

2

For the signatures, hash-based signatures provide a nice solution to your problem: You can use so called hash combiners to instantiate the signature. These are functions that construct a hash function given two or more hash functions and preserve certain properties as long as at least one of the hash function has this property. For example the concatenation ...

1

If you store the encrypted digests in one location, the key in another, and send the new digest and encrypted one from the first location to the second --- you probably have much better chance to have your communications intercepted with both plaintext and ciphertext revealed compared to the chance that your encrypted database is leaked. If you still ...

0

Either is safe, but I would prefer encryption for two reasons: As noted in the comments, you can change the key without needing to know the original password. Encryption doesn't add to collisions, while HMAC can. The probability is tiny, but it adds to the probability that the password hash caused a collision. Not worth worrying about, but since it's ...

3

If your IV is predictable this is as (in)secure as assuming that you have a zero vector IV. And a zero vector IV allows you to perform a so-called Adaptive Chosen Plaintext Attack (ACPA). Why? Assume that you have a encryption mechanism that works in CBC mode. This means, that on the first iteration the $IV$ is XORed with your input message (which is ...

2

In short: does storing these encrypted files in an encrypted partition/folder create the same potential weaknesses as cascade encryption? If not, what of encrypting a .tar of encrypted documents? An encrypted file inside an encrypted container is a cascade of ciphers, almost by definition. Is that a problem? Not really. A cascade of ciphers shouldn't ...

1

Your parameters that you provide are incomplete (in what group are you working?). Anyways, lets assume that you work in $\mathbb{Z}_p^*$, your have a generator $g$ and your public key is $y=g^x$. Then, if two ciphertexts share the same randomness $k$, they will look like $(c_1,c_2)=(g^k,m\cdot y^k)$ and $(c_1',c_2')=(g^k,m'\cdot y^k)$ for your two messages ...

0

It might be worth pointing out that the Boomerang attack by Alex Biryukov and Dmitry Khovratovich requires four keys. Some of the older related key attacks required $2^{35}$ keys, which makes the attack much harder in practice. But forcing a target to rekey four times is quite realistic.

1

What is the probability that both [Hu] = [Hmu] and [He] = [Hme]. In english, what is the chance that two different files can have identical hashes in both an unencrypted and encrypted form? Depends on whether they are "random" files or attacker controlled. MD5 is a 128-bit hash, so for two random files that differ the probability that they have the ...

2

It'll be the same situation that NY City suffered some days ago: when you have little variability on your data, i.e., they have a fixed-small size, it'll always be fast to brute force. You don't say how long your number is, so I'll assume it can range from 0 - 10,000,000,000 (so, a unique number for each human being on Earth today, plus some spare). You ...

3

The problem is almost exactly the same as in password based key derivation, so you could use a similar solution. Derive a master secret from your password and a unique salt using e.g. PBKDF2 or scrypt: $S_m = PBKDF(p, s)$. Derive a site-specific secret from the master using e.g. HKDF and the site URL: $S_u = HKDF(S_m, u)$. Turn the site secret into a ...

3

If the plaintext format is indeed as you describe, then you're out of luck: the insertion of the newlines and the consequent shifting of the plaintext records is enough to disrupt any structure in the ciphertext. If the plaintext were longer, say, 8 records, then it could work, but with just 7 records there's no way to switch the first and last record ...

-4

Well, DES is weak and since you can guess a plaintext you can use a rainbow table to crack the key and then of course decrypt and re-encrypt the message. Apart from that I don't think you can re-order the blocks to change the first and last line, if you really want to do this specific operation.

Top 50 recent answers are included