# Tag Info

12

Synchronous stream cipher, or just stream cipher. In a synchronous stream cipher a stream of pseudo-random digits is generated independently of the plaintext and ciphertext messages, and then combined with the plaintext (to encrypt) or the ciphertext (to decrypt). In the most common form, binary digits are used (bits), and the keystream is combined with ...

9

No, you can reuse a message as often as you want with the OTP. (But never reuse the key!) What happens if you reuse a key? The attacker can xor the two encrypted messages (ciphertexts) and gets the xor of the two plaintexts. The xor of two messages is highly insecure and can be easily turned into two plaintexts with some know patterns. What happens if you ...

5

First of all there does exist information theoretically secure message authentication codes suitable for use with a one time pad. An HMAC is not one of those information theoretically secure. As far as I recall the first article presenting such a construction is the 1981 article by Wegman and Carter: New hash functions and their use in authentication and ...

5

This is not a mathematical proof. A notable place it fails to be a proof is here: Pay attention to which cipher text I use, look up to match the message with the cipher-number below. $$cipher1⊕cipher3=character1⊕character3⊕IV1⊕IV2$$ (Note that the cipher BOTH use the SAME KEY, but they remain secure because of the two different IV) This line is ...

5

At least, doing the goof of reusing the OTP makes one vulnerable to disclosure of any of the key, which trivially reveals all the others. For the rest, the consequences depends heavilly on what the keys are intended for. If the keys are intended for a block cipher that is secure including under related-key attack (as AES almost is), then there is not ...

4

The system described in the quoted article depends on the security of AES for random keys (not only on the theoretical unbreakability of the OTP) in at least at least two things: the encryption of large files, as apparent in the quotes of the question; the initial establishment of the OTP, as shown by this other quote The first step is always optical, ...

4

Since bits are independently generated, the entropy of the key is the sum over the entropy of the individual bits. The following calculations use the chance $P(x)$ of a zero or one bit. The first 5 bits are constant and thus have 0 entropy. The others are unbiased and have 1 bit of entropy each. $P(0)=P(1)=0.5$. $-2\cdot(0.5 \cdot \log_2(0.5))= ... 4 A one time pad (OTP) should by definition not have any patterns. An entropy source can have patterns, but an OTP by definition should consist of pure random bits. In general you can create something that is close to a true random number generator by applying a cryptographic hash function over the output of an entropy source. According to NIST you should ... 4 Not as secure as a one time pad. A key concept with one time pads is that no part of them is ever reused. It is a common pitfall of people attempting to implement cryptography to assume that an obscure relationship is necessarily a secure one: it is not. You are create a chain of SHA hashes that can be observed, and potentially decoded. Therefore what you ... 4 If you perform the distribution digitally (using networks) then you have a problem. Unless you use another one time pad you lose the perfect confidentiality as the distribution itself won't deliver perfect security. But using another one time pad is pointless: you would lose exactly as many key bits as you are distributing, while you are only protecting the ... 3 No, because then you could calculate$z_1 \oplus z_2 = (m_1 \land m_2) \oplus (m_1 \lor m_2) = m_1 \oplus m_2$. In practice, you can only find$m_1 \oplus m_2$if both$m_1$and$m_2$are encrypted with the same OTP (i.e.,$(m_1 \oplus y_1) \oplus (m_2 \oplus y_1) = m_1 \oplus m_2$). So without any knowledge of$m_1$,$m_2$,$y_1$or$y_2$, there is no way ... 3 It depends on what you think of as an alternative. If you think of the scheme where you do not use$M$as a modulus, but the keys a picked as: $$k \leftarrow \{1, \ldots, M-1\}$$ Encryption: $$C = d + k$$ Decryption: $$d = C - k$$ Then the scheme is insecure. One way to see this is to note that we have$C \geq d$. So the ciphertext communicates the ... 3 Simply put: No. First recall that this is a mis-use of the term "One Time Pad" So lets call it a vigenere cipher instead. You can determine this is insecure with a simple algebraic combination:$ \text{attack} = cipher_1 + cipher_2 + cipher_3 + cipher_4 \\ \text{Simplify: } \\ \text{attack} = character_1 + key_1 + IV_1 + character_2 + key_2 + IV_1 + ...

3

For a scheme to be information-theoretically secure, you need that $$\Pr[M=m\mid C=c]=\Pr[M=m\mid C=c^\prime]$$ for all $c,c^\prime$ (that is, any ciphertext has the same probability $M=m$, so the ciphertext doesn't change the probability $M=m$). Let's suppose we have a $c$ and a $c^\prime$. Both of them have the same number of ones and zeroes, because both ...

3

Note: In this answer, I stick to a definition of the One Time Pad where the random pad is used only One Time; at least, I've the name of it as support! Otherwise, it is well known that the OTP encryption scheme consisting of XOR with a repeated key is insecure by even the weakest standard (unknown plaintext with redundancy). INDistinguishability under ...

2

The standard random number generator, in languages like Java or Python, does not generate real random numbers but pseudorandom numbers determined by an initial seed value. If an attacker can somehow guess or determine this seed value, they can reconstruct the entire sequence of pseudorandom outputs. Furthermore, the default pseudorandom number generators ...

2

You're on a middle path here, and the main question is: What do you want to hide? What can the attacker see before/after the change? The least secure one is: Just XOR the bit changes on the ciphertext and be done with it. The information theoretic property still holds: If the attacker has exactly $0.5$ chance of guessing a single bit, and it was changed ...

2

If you only ever use a particular OTP block to encrypt one plaintext block, there is no way to decrypt it. However, with your approach anyone looking at multiple versions of the file will be able to tell which parts have changed. For example, if the file contained secret messages stored by users, it would leak the length of each message added. Maybe that's ...

2

No. As the key should be fully random - a premise that invalidates the use of an OTP in practice - that should not matter at all.

2

For the one time pad, your key must be The same length as the message. Whatever your unit of measurement (bits, bytes, etc), they must be the same length. The key must be perfectly random. The key is only ever used once.

2

The proof for the perfect secrecy property of the one time pad is quite simple. It makes use of basic probabilities and it says that: $$Pr[M=m|C=c]=Pr[M=m]$$ for a probability distribution M$\{0,1\}^n$ for the message space and a probability space C for the ciphertext space. Proof: Pr[C=c]=\sum{Pr[C=c|M=m']\cdot Pr[M=m']} =\sum{Pr[K=m'\oplus c]}\cdot ...

2

Could someone even recognize that the values are encrypted? Well, maybe, maybe not. You're correct that the values would all appear to be valid dates (this is known as format-preserving encryption, by the way), so they would not look obviously encrypted, the way, say, a random hex string would. If someone just saw a small number of such dates, with no ...

2

Yes, the same weaknesses apply. Text on computers is a bunch of numbers; a OTP encrypts a sequence of numbers modulo 2.

2

Imagine that you have a ciphertext: Perfect secrecy means, that without knowing the key, any plaintext has to be a possible preimage. Because otherwise the ciphertext would give you information about the plaintext. Encryption is an injective function, because otherwise it could not be reversed. That means, for a given key and ciphertext you have at most ...

2

Actually, it's not a hare-brained idea at all; you certainly can do integrity checking using a one-time pad. However, I believe that you'll need to use the one-time pad bits a bit faster than you'd expect, to achieve a forgery probability of at most $2^{-32}$, I believe you'll need at least 64 pad bits per packet (assuming informational theoretical security ...

2

First, the system as I understand it does not use a one-time-pad at all, but a steam cipher. The keystream is generated via a CSPRNG, and is not truly random, so it cannot be a one-time-pad. They are misrepresenting it. But, to answer your question, let's assume the system did in fact use a one-time-pad, and used it in the manner described. In this ...

2

Let's just consider keys of bitlength 1, it works like that for any length. We have $k_1$ and $k_2$, the 2 random keys. And we have $k_3$, the OTP key. And then we give $x_1 = k_1 \oplus k_3$ and $x_2 = k_2 \oplus k_3$ to the attacker How can you attack the OTP? You can't. However, you don't need it. Because $x_1$ and $x_2$ quite obviously reveal a lot ...

2

You need to understand that any variation on the OTP would ultimately be equivalent to the OTP security-wise, since it is unconditionally "secure" (the ciphertext leaks zero information about the plaintext or the key), and so you'd just making it harder to compute for now reason. So, sure, you can use the OTP, or some variant thereof, on 128-bit messages ...

1

To answer the question of whether they would need some special technique to OTP encrypt a message longer than their key: No, to realize their claim of more than 3000 text messages they can use standard OTP. You are correct that with 0.5MB OTP key you can encrypt at most 0.5MB of data. 0.5MB is 500.000Bytes meaning as many characters can be encrypted ...

1

Use AES-128, the instruction set in most CPU's (AES-NI) speeds up the encryption and does not put to much load on your CPU. I would use CBC but there might be better mode operations for encrypting files. Also don't forget to use a MAC. Using a one time pad (OTP) is nice but what you're doing is not an OTP it's more a Vigenère cipher. If you were to use OTP ...

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