4 ms·

is this unbreakable like OTP?

triska 5y ago
No, because the key stream is not random: It depends functionally on the integer which is sent in plain text, and on the shared secret. For example, if you pick the same integer twice with the same secret then the XOR of the two ciphertexts is the XOR of the two plaintexts, thus losing confidentiality.
- Karliss 5y ago
  Neither is OTP secure if you reuse the key. One of main properties of OTP is that an encrypted message could be decrypted to any message of same size. In case of block cyphers and message longer than one block only a fraction of all messages can be obtained. So if you had enough compute resource(and it wasn't more than atoms in universe) for brute force or weakness was found in cyphers you could find which of the potential decrypted messages makes sense and is more likely.
  - smitty1e 5y ago
    > Neither is OTP secure if you reuse the key. I thought the OT meant "One Time". Reusing the key would take the key from singular to plural usage, no?
    - Closi 5y ago
      Absolutely - OTP with key reuse is not OTP!
    - pdpi 5y ago
      Yup, but it’s more useful to talk about that reuse as a bad implementation of one-time pads than it is to call it something other than OTP. In the classic sense of a small paper pad used by spies, reuse was fairly common because of the logistical problem of supplying agents with fresh pads.
    - Karliss 5y ago
      Yes, but I was explaining that no reuse requirement can be equally important for encryption schemes that don't have it included in the name. Claiming that one of them is worse than other because of number reuse even though doing so is equally wrong for both is not a good example.
- runeks 5y ago
  Would it be secure to encrypt a sequence of blocks by having the next integer be H(k) — such that the random integer for block number i is H applied to the original random integer (k) i times? Thus needing only an initial random integer from which all subsequent random integers are derived.
  - eternalban 5y ago
    The general idea is to create a PRNG using the cryptographic hash. Since these hashes generally produce far more bits than needed for scalars (64 bits), you can mix the extra bits for the next cycle of the PRNG and emit (say) 64 bits per cycle. The sequence of the PRNG output is the 'pad'.
aliceryhl 5y ago
No. With the hash-based algorithm you can go through every possible secret key and starting integer and check whether the result looks like English text (or whatever the contents are). If your English-text check is sufficiently good (how good it has to be decreases with the length of the text), then you're only going to have a very small number of matches, and one of those will be the plain text. The above attack doesn't work on OTP because the above attack would simply yield a list of all English strings of the given length, and there would be no way to tell them apart. Obviously the above attack is infeasible because there are too many secrets to check them all in a reasonable amount of time, but to be unbreakable in the same way OTP is, you have to be robust against even attacks that take an infinite amount of time.
- akerl_ 5y ago
  I’m not sure what you mean by “the above attack would simply yield a list of all English strings of a given length”. To attack classic OTP, you’d brute force the keyspace. Since we’re XORing, whatever we encode the key as, it’s fundamentally being used in binary to XOR between plaintext and ciphertext. So your key is a binary blob the same length as the ciphertext. You keep trying and looking for what seems to be viable plaintext. You never get “all English strings of the given length”, because you’re not brute forcing the output, you’re brute forcing the key, which isn’t necessarily English. For the hash-based approach, you’re bruteforcing the secret used for the hash function. That keyspace can be any length, unbounded on either end by the size of the message. Likewise, you’re trying H(sk) by guessing s and k, and then XORing the message and trying to determine if it looks like what you’d expect. Your lower bound for the hash method is if the message length is shorter than the hash functions output, in which case you can cheat and literally just treat it like classic OTP, by bruteforcing possible values for H(sk) rather than guessing k and running the computation. But beyond that it’s the same dance (and if the hash function is slow, you can always fall back to brute forcing any length message the same way you would for classic OTP). In both cases, assuming a large key size puts you past computational sanity for brute forcing, but neither the hash construction nor OTP is secure against “infinite” time.
  - eperdew 5y ago

No, because the key stream is not random: It depends functionally on the integer which is sent in plain text, and on the shared secret. For example, if you pick the same integer twice with the same secret then the XOR of the two ciphertexts is the XOR of the two plaintexts, thus losing confidentiality.

Karliss 5y ago
Neither is OTP secure if you reuse the key. One of main properties of OTP is that an encrypted message could be decrypted to any message of same size. In case of block cyphers and message longer than one block only a fraction of all messages can be obtained. So if you had enough compute resource(and it wasn't more than atoms in universe) for brute force or weakness was found in cyphers you could find which of the potential decrypted messages makes sense and is more likely.
- smitty1e 5y ago
  > Neither is OTP secure if you reuse the key. I thought the OT meant "One Time". Reusing the key would take the key from singular to plural usage, no?
  - Closi 5y ago
    Absolutely - OTP with key reuse is not OTP!
  - pdpi 5y ago
    Yup, but it’s more useful to talk about that reuse as a bad implementation of one-time pads than it is to call it something other than OTP. In the classic sense of a small paper pad used by spies, reuse was fairly common because of the logistical problem of supplying agents with fresh pads.
  - Karliss 5y ago
    Yes, but I was explaining that no reuse requirement can be equally important for encryption schemes that don't have it included in the name. Claiming that one of them is worse than other because of number reuse even though doing so is equally wrong for both is not a good example.
runeks 5y ago
Would it be secure to encrypt a sequence of blocks by having the next integer be H(k) — such that the random integer for block number i is H applied to the original random integer (k) i times? Thus needing only an initial random integer from which all subsequent random integers are derived.
- eternalban 5y ago
  The general idea is to create a PRNG using the cryptographic hash. Since these hashes generally produce far more bits than needed for scalars (64 bits), you can mix the extra bits for the next cycle of the PRNG and emit (say) 64 bits per cycle. The sequence of the PRNG output is the 'pad'.

aliceryhl 5y ago

No. With the hash-based algorithm you can go through every possible secret key and starting integer and check whether the result looks like English text (or whatever the contents are). If your English-text check is sufficiently good (how good it has to be decreases with the length of the text), then you're only going to have a very small number of matches, and one of those will be the plain text. The above attack doesn't work on OTP because the above attack would simply yield a list of all English strings of the given length, and there would be no way to tell them apart. Obviously the above attack is infeasible because there are too many secrets to check them all in a reasonable amount of time, but to be unbreakable in the same way OTP is, you have to be robust against even attacks that take an infinite amount of time.

akerl_ 5y ago
I’m not sure what you mean by “the above attack would simply yield a list of all English strings of a given length”. To attack classic OTP, you’d brute force the keyspace. Since we’re XORing, whatever we encode the key as, it’s fundamentally being used in binary to XOR between plaintext and ciphertext. So your key is a binary blob the same length as the ciphertext. You keep trying and looking for what seems to be viable plaintext. You never get “all English strings of the given length”, because you’re not brute forcing the output, you’re brute forcing the key, which isn’t necessarily English. For the hash-based approach, you’re bruteforcing the secret used for the hash function. That keyspace can be any length, unbounded on either end by the size of the message. Likewise, you’re trying H(sk) by guessing s and k, and then XORing the message and trying to determine if it looks like what you’d expect. Your lower bound for the hash method is if the message length is shorter than the hash functions output, in which case you can cheat and literally just treat it like classic OTP, by bruteforcing possible values for H(sk) rather than guessing k and running the computation. But beyond that it’s the same dance (and if the hash function is slow, you can always fall back to brute forcing any length message the same way you would for classic OTP). In both cases, assuming a large key size puts you past computational sanity for brute forcing, but neither the hash construction nor OTP is secure against “infinite” time.
- eperdew 5y ago