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

6

Actually, the problem with OTP isn't the storage of the pad (although secure erasure of the parts of the pad you used is trickier than it looks), and it isn't the pad generation (although, again, that's trickier than it looks), but the secure transport. After all, it's not enough for you (Alice) to have the secure pad, you also have to give a copy to the ...

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

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 ... 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 In modular calculations such as this, the divisor (in your case 26) must be at least the size of your character code space. Your code space is 46 characters, so that is not going to work. Any output of the modular calculation will be less than the divisor, so you will never get 83 for x mod 26, it is not going to happen. For a 46 character code space, 46 is ... 3 Perfect Secrecy (or information-theoretic secure) means that the ciphertext conveys no information about the content of the plaintext. In effect this means that, no matter how much ciphertext you have, it does not convey anything about what the plaintext and key were. It can be proved that any such scheme must use at least as much key material as there is ... 3 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, ... 2 It is safe, in the case that you have MACs which are independently keyed (or at the very least, the cryptographically secure MAC is independently keyed from all the other ones). This can be seen not by an argument from randomness, but from a simple observation that it were not true, then an attacker could attack the secure MAC by generating the insecure ... 2 Perfect secrecy is the notion that, given an encrypted message (or ciphertext) from a perfectly secure encryption system (or cipher), absolutely nothing will be revealed about the unencrypted message (or plaintext) by the ciphertext. A perfectly secret cipher has a couple of other equivalent properties: Even if given a choice of two plaintexts, one the ... 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 Well, for perfect secrecy, we require that for all message distributions over$\mathcal{M}$, all messages$m\in\mathcal{M}$, and all (possible) ciphertexts$c$it holds that $$Pr[M=m\ |\ C = c] = Pr[M=m]$$ In particular, that means, if we can find a single counterexample, i.e. a distribution over$\mathcal{M}$, a message$m\in\mathcal{M}$, and a ... 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 Your calculator is correct: $$105-48 = 57 \equiv 5 \pmod{26}.$$ Your Python code, however, calculates 105 - 48 % 26, which Python, due to its operator precedence rules, evaluates as 105 - (48 % 26) = 105 - 22 = 83. To get the correct remainder modulo 26, you need to add parentheses to your Python code so that it reads (105 - 48) % 26 instead. This will ... 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 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 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 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 ... 1 In cases where Alice and Bob are guaranteed to arrive at the same key, this is impossible: the function that takes Alice and Bob's private info as input, and produces the public transcript as output, must be a one-way function if the scheme is to be secure and if it always negotiates a shared key. If it sometimes fails, then you don't necessarily get a OWF; ... 1 Actually, you are quite correct; you have not been given enough information to determine the probability. The piece of information that you have not been given is the probability distribution that the plaintext was originally chosen from. Perhaps all 128 possible plaintexts were chosen with equal probability (that is, with probability$1/128\$). Perhaps ...

1

This question is not really well defined. If by "Would this actually work?" you mean "Will this be as good as using a one time pad of length y" then the short answer is No. Anything susceptible to a brute force attack is not as secure as a one time pad. What are you trying to achieve? If you already agreed on a key of 512 bits and assume this is the ...

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