Tag Info

Hot answers tagged

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

To answer your question: no this is not homomorphic encryption because one of the plaintexts is used unencrypted. There may be times when it is a useful property, but the only uses I know of it are to demonstrate the malleability of xor ciphers. To be a homomorphic encryption function, it should be possible to calculate the encryption of some function of ...


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

We typically refer to a homomorphic cipher if we can take two ciphertexts and combine them in a way that has a predictible result on the plaintexts. In your example you have taken one ciphertext and one plaintext. Using a stream cipher correctly you should never have 2 ciphertexts encrypted with the same portion of a keystream. So, combining two ciphertexts ...


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

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


3

This is called an Even-Mansour cipher. Actually, for the differential cryptanalysis it does not matter what sort of difference you use, you only need that it propagates deterministically through linear transformations (whatever linearity means). In this case you use a difference modulo $2^{32}$: $$ A \boxminus B \equiv (A-B)\pmod{2^{32}}. $$ You compute ...


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

A better way to solve your problem is: on the server, encrypt the document under a document encryption key (a unique key that's specific to that document). The document remains encrypted in storage encrypted under this document key. When a client requests the document, send the client a copy of the encrypted document, as well as an encryption of the ...


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


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

Apart from the obvious security vulnerability from using a simple XOR operation to convert between plaintext and ciphertext you also run into the massive security-flaw of each identical plaintext generates identical ciphertext. In any given message, if a constant cipher operation is used along with a constant key, the resultant ciphertext will be same for ...


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


1

There are a reasonable number of assumptions I'm going to have to make to try and answer this question. For perfect security, we require that the keystream is truely random, and never reused (OTP,shannon). I've decided to add in a short answer here: STOP! There's absolutely no need to use a reduced character set thing anyway - you can just use your random ...


1

The answer is almost definitely no for what I think you want (question is still unclear). I was hoping someone else could give a definite no, but since they haven't I figured I'd write this up. Your exact secret sharing method probably needs to be fully described in the question. I'm going to assume that $a=a_1\oplus a_2\oplus\dots\oplus a_n$ and similarly ...



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