Tag Info

Hot answers tagged

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


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

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

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

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


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

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

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

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

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

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

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


1

If the key would be smaller than the plaintext then you could brute force the cipher by using less than $N$ steps, where $N$ represents the amount of possible messages. Of course the brute force approach is an upper bound to what can be tried. If there are attacks on the cipher (that are less complex than brute force) then the plaintext may be recovered ...


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


1

Here's a more "down to earth" example. The following cryptosystem with plaintext space $\mathcal{M} = \{a,b,c,d\}$, keyspace $\mathcal{K} = \{1,2,3,4\}$ and ciphertext space $\mathcal{C} = \{A,B,C,D\}$ has perfect secrecy: $$\begin{array}{c|c c c c} & 1 & 2 & 3 & 4 \\ \hline a & A & B & C & D \\ b & B & C & D ...


1

Through repeated DH attempts, could Alice and Bob build a large random key for use as a one-time pad? No, since that is not how a one time pad works. You can use your idea to create cryptographic material to encrypt plaintext using XOR, what you are describing is an asymmetric stream cipher of some sorts. A one time pad requires an "offline" exchange ...


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



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