# Tag Info

15

They are both linear, but in different algebraic Groups. Which is to say, xor is linear in any finite field of characteristic 2, while 'ordinary' addition is linear in the infinite field of the Real numbers. Addition modulo $n$ (which is more cryptologically significant than addition over the Reals) is also a linear operation, but in the ring of integers ...

11

Yes, it's the same XOR. It gets used inside most of the algorithms, or just to merge a stream cipher and the plaintext. Everything is just bits, even text. The word "hello" is in ASCII "01101000 01100101 01101100 01101100 01101111". Just normal bits, grouped in 5 bytes. Now you can encrypt this string with a random string of 5 bytes, like an One-time pad. ...

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

8

What is the definition of linearity? Linearity is defined for maps between vector spaces. If you have a field $F$ and two vector spaces $U$ and $V$ over the field $F$, a map $$T:U\rightarrow V$$ is said to be linear if $$T(\gamma_1\odot u_1\oplus\gamma_2\odot u_2)=\gamma_1 \odot T(u_1)\oplus\gamma_2\odot T(u_2)$$ whenever $\gamma_1,\gamma_2\in F$ and ...

7

It is possible to turn a hash function into a stream cipher; there are several methods for that, and the simplest is to compute $h(K||IV||x)$ for hash function $h$, initialization vector $IV$, and successive values of a counter $x$. This yields an arbitrarily long sequence of pseudo-random blocks (32 bytes per invocation if $h$ is SHA-256). Then XOR that ...

6

Some brief thoughts: Shared secret Generation: $$s=E_a(B)=E_b(A)$$ The shared secret is generated by encrypting the other users public key with your private key. This is effectively an ECDH step, which is very reasonable, and one of the key aims of C25519$^{[1]}$. Key Generation: $$s_0=\mathrm{SHA256}(s); s_i=\mathrm{SHA256}(s_{i-1})$$ First, using the ...

5

Yes, the XOR used in cryptography means the same bitwise XOR operator you're familiar with. And yes, to securely encrypt a message with XOR (alone), you do need a key that is as long as the message. In fact, if you have such a key (and it's completely random, and you never reuse it), then the resulting encryption scheme (known as the one-time pad) is ...

4

Your cipher is a synchronous stream cipher build on a random number generator. For cryptographically secure random number generators (CSRNG), this is a secure stream cipher. The problem is, that your random seed is way too small for any security. Trying all possible seeds and seeing if the decryption result makes some sense (assuming the plaintext makes ...

4

The two plaintexts are almost certainly identical. At the very least, any difference between them must be representable in 32 bytes, since that's as much information as the XOR of the encrypted files contains. Assuming that the plaintexts are indeed identical, we can also see that changing the encryption key has a very simple and predictable effect on the ...

4

For simple XOR-based encryption algorithms such as OTP, the key size must be the same as the message size. If you choose a smaller key and try to divide the message into chunks, you would not have a perfectly secure scheme anymore. Now, since you tagged java, I'm assuming that this increase in time for smaller key sizes is due to the code trying to divide ...

3

Rather than LuaCrypto or some other Lua binding to some (blazing fast) low-level cryptographic library in some other language; I'm assuming that you want a "pure Lua" implementation. Would one of the following work for you? ARCFOUR in pure Lua (a) (b) (c) (d) Lua wiki: Cryptography (b) Pure LUA encryption (d) "Very simple string Encryption"(w) (k) yet ...

3

What is the significance of the repetition? Does it mean that a 6 character key was used and repeated across the same characters within $P_1$ and $P_2$? I'm assuming your assumption about this being an xor cipher with the pad used twice for two ciphertexts. It does not mean a 6 character key was used. A one time pad used twice could result in this ...

3

You mention hardware complexity, but there definitely is more software complexity in using XNOR. Most programming languages have a XOR operator, but no XNOR. Likewise, assembly languages lack XNOR (at least x86 does). That means it would basically take twice the cycles to use XNOR in place of XOR, except where two XNORs would cancel and you'd be back to XOR. ...

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

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

Paŭlo Ebermann has given a good answer from a strict cryptographic perspective, and David Cary has given many useful engineering considerations. I want to add, or maybe prefix, these answers with some more engineering considerations. The main problem is that bitwise operations in Lua (5.2 at least) are very slow and the implementation ComputerCraft can ...

2

There are two possibilities here: AES is secure, in which case no one can open your encryption without knowing your keys, regardless of whether you layer anything else on top of AES. AES is not secure and someone knows how to break it. In that case the security of your encryption might only be as strong as the second layer of encryption. In neither case ...

2

It turns out that this is not very difficult to solve. It also looks like this is part of a public cryptography challenge, so rather than giving it all away, I'll just provide you with a couple of pointers. First take a look at this: There is a clear repeating pattern every 5 bytes. This suggests two things: (i) an XOR key with a length of 5 was used ...

1

This question as stated actually has a fairly interesting and unintuitive answer. Assuming an 8 byte 64 bit xor key and your test for printable ascii characters then after a megabyte of correct data your chances of having the right key are... about one in four billion. This is completely independent of how much data you have or verify, 1/2^32 is the maximum ...

1

For CBC mode, the IV must be Never used twice with the same key Unpredictable So, in your example (filename$\oplus$key), if you ever encrypt two files that have the same filename with the same key, you will violate #1. Now, you may be tempted to say "but I always generate a new key for every file that I encrypt, so that example doesn't apply". Fine, ...

1

I need to encrypt an ASCII string [a-zA-Z0-9:] to an ASCII [a-zA-Z0-9] string of the same length. The pigeonhole principle can be used to explain why it is not possible to encrypt every 15-character string from some set of sixty-three characters into an encrypted 15-character string from a set of sixty-two characters. I need to encrypt an ASCII ...

1

I don't really know what the point of this but I think that's already covered in the comments above. So, about your Vernam cipher resp. One-Time-Pad: The "trick" of the OTP - and we can prove mathematically that it is secure - is that the key has to have the same length as the cipher text and also we assume the key was send over a secure channel (what ever ...

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