# Tag Info

11

Very short answer: No Quite Short answer: No, because a scheme can only be a One-Time-Pad if the entire pad is perfectly random and secret. Concise answer: It sounds like you're trying to build a stream cipher. The security of it really comes down to how much of the scheme you think can be kept secret. If I listen in to your wifi and hear you requesting a ...

9

The general scheme is called Three-pass protocol and works for all commutative ciphers. It is secure for some of them, but xor (and modular addition) are insecure choices. Your scheme: A->B: $c_1 = m \oplus a$ B->A: $c_2 = c_1 \oplus b$ A->B: $c_3 = c_2 \oplus a$ B computes $m = c_3 \oplus b$ an attacker sees all of $c_1$, $c_2$ and $c_3$. So they can ...

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

What you've described is generally called a "book cipher" or "Ottendorf cipher", where the "key" is knowing which publication is being referenced, as well as the algorithm for recovering information from it. A hundred years ago they were quite secure because not only were books fairly rare, but trying every book against an unknown cipher was very time ...

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

Assuming that you have not used the one-time pad bits $k_2, ..., k_{N+1}$ to encrypt another message, then the answer is no, the attacker cannot determine the message. This can be seen by using the normal proof of One Time Pad's security; the bits $k_2, ..., k_{N+1}$ are random and uncorrelated to any other bits the attacker has access to; hence the ...

4

Well, for one thing, you are not using a "One Time Pad". A "One Time Pad" means, by definition, that someone generates a pad of numbers using true randomness (and not algorithmicly), and that no potential adversary has any information on what that pad may contain. Then, that pad is given to both the sender and the receiver, and then the sender uses it to ...

4

All of the responses so far have answered your question, but it is interesting to note that this method of collecting random mouse movements has been implemented before by a commercial Certification Authority. I speak from first hand experience of using this, because I worked for the company the created it. Baltimore Technologies (now Verizon Enterprise ...

4

If your key material is properly random and at least as long as that which is to be encrypted, and indeed each key is used only once, then one-time pad is indeed applicable. As was noted: Distribution of keys will be a hard problem. OTP makes practical sense only in scenarios where keys can be distributed at some time T, then used for encrypting and ...

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

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))= ... 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 You can construct a one-time MAC that has a similar properties to the OTP. Better still, it uses a fixed number of bits for each message. Here's how it works. Choose the closet prime to your message block size. Let's say you plan to process 128-bit chunks of your message. Let's say there are$L$such blocks. The first job is to pick the first prime larger ... 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 ... 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 AFAIK, no one has proven that AES on a single 128-bit block with a true-random 128-bit key does not provide information theoretic security (such a proof would probably be the end of AES as it would demonstrate a weakness). OTOH, no one has proven that it does. I suppose it is possible that it does, but such a proof is likely to be extremely difficult. Just ... 2 If you using in one time pad key shorter then message, it means that some part of text will be encrypted with same part of key, two or more time. In this case, XORing two part encrypted with same key, adversary can receive few information about plaintext. If key significantly shorter then plaintext, adversary can apply frequency analysis to discover whole ... 2 You can use PBKF2 key generation function. Use some integer generated by the mouse movement as the input. PBKF2 function will give you a random output with more entropy than the input. 2 The OTP is more a theoretical construction than a real world construction. The OTP suffers from three core problems: Key Generation. Key Distribution. Key Destruction. Let's deal with each one in turn. Key Generation Key generation is surprisingly difficult. In order to get the full security proof for the OTP, you need to each bit to be independent of ... 2 One can efficiently obtain a$\:GF\left(2^n\hspace{-0.02 in}\right)\:$either by$\;$looking up the simplest binary irreducible polynomial of$\;$degree$n$here and verifying that it is in fact irreducible$\;\;\;$or$\;$using this unconditional and deterministic algorithm to compute such a polynomial . For any such$\:GF\left(2^n\hspace{-0.02 ...

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

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

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 >= d. So the ciphertext communicates the ...

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.

1

The one-time pad operates on bits and bytes and is agnostic to what symbols those bytes represent, so, yes, you should be able to use numbers as well. When it comes to the Vernam cipher the answer is "you should, but for some reason you can't". That reason is most likely the fact that, although Morse code does encode digits, they don't appear to be used ...

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