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

8

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

7

Let's say Alice and Bob have $c$ bits of pre-shared secret key material. Alice generates $a$ bits of new key material, concatenates it to a message $M$ that is $b$ bits long, and uses $a+b$ bits of their pre-shared key material to encrypt "message||new-key". She sends this secure message to Bob, who decrypts it with the shared key. Now they both have $a$ ...

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

If "this message" is the plaintext, then that doesn't actually help, since encrypting the new secret key uses up an amount of the old pad equal to the length of the new secret key, the total length of all "actual messages" will still be limited to the total length of the original one-time pad. If "this message" is the ciphertext, then an eavesdropper will ...

5

There are four concerns here: Pad generation Pad transmission Message privacy Message authenticity Pad generation The security of the one-time pad depends on the assumption that the pads are generated from a truly random source. This is actually quite a big ask. Suppose for a moment that you want to exchange a 4 gigabyte pad. Let's say your RNG does ...

5

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

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

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

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 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 (The below may be a bit cryptic if you don't know Python.) The idea is not to decode the message, but to manipulate it. Since your ciphertext is C = OTPkey ^ "attack at dawn" all you need to do is to XOR the last 4 bytes of the ciphertext with the original text "dawn" and then again with "dusk", for example: C ^ "attack at dawn" ^ "attack at dusk" ... 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 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 From RFC 4226: 7.4. Resynchronization of the Counter Although the server's counter value is only incremented after a successful HOTP authentication, the counter on the token is incremented every time a new HOTP is requested by the user. Because of this, the counter values on the server and on the token might be out of synchronization. ... 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 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 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 If you know the plaintext and the ciphertext, getting the key is trivial. $$c=m \oplus k$$ Try moving the terms around. Hint:$m$and$k$can be functionally swapped (change position with each other), ie. only one term needs to be secret. You already know one term. I've pretty much given you the answer. About the decoding procedure: The ASCII table ... 2 As well as Simon Johnson's suggestions you should think about the following: When collecting the entropy you'll need to ascertain the speed at which the hardware random number generator provides entropy. The collection program may need to be in a loop so waits for more entropy to become available (similar to /dev/random). Think about other sources of ... 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

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

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

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