Anna wants to send a message with a random arrangement of only 5 words, which are
INPUT, GET, HTTP, OUTPUT, POST
like
INPUTGETOUTPUTPOSTGETHTTPHTTPINPUTGET
Each letter occupies 1 byte, and the entire message will be aligned to an integer multiple of 128 bits by adding 0 at the end of the message.
After getting the message to be sent, Anna divides it into several 128-bit (16 bytes=16 letters) plaintext blocks from beginning to end, like
INPUTGETOUTPUTPO, STGETHTTPHTTPINP, UTGET00000000000
Randomly pick 2 plaintext blocks P1 and P5, and use a same 128 bit key to get cipher block C1 = P1 xor key C5 = P5 xor key.
Now suppose I am an adversary. I know all the above encryption algorithms, and intercepted 2 ciphertext blocks CA and CB, and can determine that 2 ciphertext blocks are generated by the same key K1.
The question now is how to decrypt the key and 2 plaintext blocks with the above information.
I have tried many ways, and the ideas are all broken. I am very grateful for the ideas and opinions that have helped me.
This is a version of two-time pad. I believe this is a contest question so only give you the hint.
X-or the two ciphertext
PP = CA x-or CB = PA x-or key x-or PB x-or key = PA x-or PB
Now apply one of your limited texts say OUTPUT to x-or with this PP by sliding and see that the x-or reveals some other. If you see one, now you get the position of OUTPUT in PA. Now you find some in PB too. continue...
I am trying to implement simple El-Gamal cryptosystem.
And I can't understand how to represent message as an integer between 1 and n-1.
The only thing that comes to my mind is:
if n bit length is k, then divide input message m on t | t < k bits and each piece of bits use as integer number.
I think It is wrong.
So how to represent message as an integer between 1 and n-1?
You could do that which is essentially the equivalent of using ECB mode in block ciphers, but there are attacks on this. An attacker may reorder the different blocks of the ciphertext and you would decrypt it without problem, but the received plaintext would be broken without you knowing this. This may also open the door for replay attacks since the blocks are all encrypted independently. You would need some kind of authenticated encryption.
Back to your original question. Such a problem is usually solved by using hybrid encryption. A block cipher like AES is used to encrypt the whole plaintext with a random key. This random key is in turn encrypted through ElGamal since the key is small enough to be represented in < k bits.
Now depending on the mode of operation of the block cipher this could still be malleable. You would either need to put a hash of the ciphertext/plaintext next to the random key as an integrity check. Or otherwise use an authenticated mode of operation like GCM and add the resulting tag next to the random key. Depending on k, this should fit.
Note that you should use some kind of padding for random key | hash/tag if it doesn't reach k.
I am looking for a commutative cipher - that is
E(K₁,E(K₂,P)) = E(K₂,E(K₁,P))
but is not associative - that is
E(K,P) ≠ E(P,K)
That rules out XOR, which otherwise would have been ok.
A symmetric cipher would be preferable, but an asymmetric cipher would work too.
The basic protocol I want to implement is:
Alice has a list of tokens (32-bit integers) and she encrypts each token with the same key (K0)
Alice sends the list of encrypted tokens to Bob
Bob randomises the list, encrypts each token with a separate key (K1 - Kn), labels each token and returns the list to Alice.
Alice decrypts each token with K0, leaving her a list of tokens, each encrypted with a separate key (K1 - Kn)
Sometime later, Bob sends Alice a key for a specific label (Kx)
Alice decrypts the token with Kx giving her the plaintext for the token labelled x
Bob may see the plaintext, so he must not be able to derive K0 from it given the information he was previously given.
Can someone suggest a cipher I can use and also point me to an implementation of that cipher?
I have an understanding of cryptographic protocols and applications but I don't really grok the mathematics of most of the ciphers out there. Step-by-step mathematical guides would be ok though.
I plan to implement this in Clojure so any Java libraries are also good. However, any code is good because I understand code.
It sounds like you're trying to implement "Mental Poker" (or if not, you should look up the research into it, since it's analagous to your problem).
The SRA algorithm has the properties you desire. It's a bit hard to find information on, but it is essentially just RSA except that both the e and d exponents are kept secret. Trivially:
(Pe1)e2 == (Pe2)e1
below refers to my hobbiest solution using my own cipher program in C#. program and source are free and available.
Remember the 'locked box puzzle' recounted on an SECURITY NOW podcast?
here's the episode...
Episode #33 | 30 Mar 2006 | 43 min.
Symmetric Block Ciphers
https://www.grc.com/sn/sn-033.txt
Steve says...
...Leo and I answer last week's Puzzler/BrainTeaser which explored the idea
of using two private
one-time pad "keys," like two padlocks, to securely convey a message between
two parties, neither of
whom would have the other's key. Then we continue our ongoing tour of
fundamental crypto technology by
describing the operation of Symmetric Block Ciphers...
Steve and Leo agreed that an eavesdropper seeing ALICE's cipher text before
and after encryption could
XOR both together and derive her secret key.
However, if a complex, commutative cipher which doesn't use simple XORing
to encrypt is used then I
think the key exchange would be secure and the key exchange would work.
for example...
BOB encrypts msg with his key.
ALICE encrypts BOB's encrypted above msg with her key.
ALICE sends above encrypted msg back to BOB.
BOB decrypts ALICE's above msg with his key.
BOB sends above to ALICE.
ALICE decrypts above with her key.
ALICE can now read BOB'S original decrypted cipher text and they didn't need
to exchange keys.
An eavesdropper attack will not work if the algorithm is not a simple
'xor'ing of plain text and key.
this cipher is a commutative , complex algorithm.
starting with notepad text file containing one character, an 'm'.
m is hex 6d 01101101.
 is hex c2 11000010 is 'm' encrypted by bob and then sent to alice.
ø is hex d8 11011000 is alice's encryption of 'Â' which bob decrypts to '£'
and sends to alice.
£ is hex a3 10100011 which alice decrypts to 'm' with her key.
m is alice decrypt result
an eavesdropper sees  alice's msg before her encryption.
the eavesdropper sees ø alice's msg after her encryption.
the eavesdropper xors  and ø.
11000010 'Â'
11011000 'ø'
00011010 the eavesdropper's xor result = 1a in hex.
if an eavesdropper attack worked he would have found 'E' hex 45 01001001
which is first letter of
alice's key.
this seems a simpler key exchange than PGP etc. All that's needed is that
both parties use the same
crypto program and agree on an authenticator.
I confess to being a hobbiest. If anyone wants the WINDOWS C# .NET program
and/or the source code for the cipher they
may have it/them.
below is example with longer, random keys.
PLAIN TEXT
this is a test.
BOB'S KEY
kZtOfS0kKqcRLjTNPh7OjcJKZZFLjmm5OVm02YlrBQN0zI9SxOD1zJjQcpetUbX
BOB'S CIPHER TEXT TO ALICE.
1IÎ.8Ío#"ëìAùJ'
ALICE'S KEY
O1yfuV7MpX3n4wtefUhr6YctRaeCcrrzH7LqLNRUQCMVZuL5Mr0Bw3qMeIT92hg
ALICE'S CIPHER TEXT TO BOB
µRÖ³#ïÓO,fzkÆaå
BOB DECODES ALICE'S ABOVE WHICH = BELOW.
øqqøð<ª>P¸&#<,
AND SENDS ABOVE BACK TO ALICE WHICH ALICE DECODES YIELDING...
this is a test.
I'm doing something similar and I'm using AES in OFB (output feedback) mode. In this mode, an IV (publicly known random value) is encrypted with AES using some key. The output of this is then XORed with your data. The output (before being XORed with the data) is then encrypted again to get another output to XOR with more data. This is not only commutative but reciprocal in the sense that the encryption and decryption algorithms are identical.
http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Output_Feedback_.28OFB.29
I know the question was asked long ago, but nobody seems to have suggested Massey-Omura, so here it goes. It satisfies the original requirements exactly. The original description (also adopted in Wikipedia) used the multiplicative group of GF(2^m), but any secure group (like elliptic curves) will do.
Here is a page with commutative encryption algorithms :
https://xianmu.github.io/posts/2018-09-19-commutative-encryption.html
Can someone explain how the RC2 key schedule works (particularly the very beginning of it)? i know it uses little endian, but my implementation is not working for any key except "0000 0000 0000 0000"
Test Vector
Key = 88bc a90e 9087 5a
Plaintext = 0000 0000 0000 0000
Ciphertext = 6ccf 4308 974c 267f
im assuming that the first thing to do with the key would be to change it into
bc88 0ea9 8790 5a
and yes i know RC2 is not even used anymore, but i would still like to know
The RFC says:
The key expansion algorithm begins by placing the supplied T-byte key into bytes L[0], ..., L[T-1] of the key buffer.
So if your key is 88bc a90e 9087 5a you get L[0]=0x88, L[1]=0xbc, ... L[6]=0x5a.
No need to consider any endianess here.
If you want to treat the key-buffer as 16-bit words you get:
K[i] = L[2*i] + 256*L[2*i+1]
I.e. K[0] = 0xbc88, K[1] = 0xa90e, K[2] = 0x8790. L[7] is only assigned later in the key-expansion step, so strictly speaking K[3] is undefined at this point. Feel free to choose any value you want however, since it makes no difference to the algorithm. If you select 0, you get K[3] = 0x005a.
I have some idea that it is due to some complex calculation, but i want to know about what exactly happens which takes long time than the corresponding encryption process. Any link to webpage or paper would be of great help.
Thanks
Thanks for the answers, One more Doubt, What about the Signing and verification? Will this time difference be there for Signing and verification also? Ex. Signing requires more time than Verification?
Let's call n, d and e the RSA modulus, private exponent and public exponent, respectively. The RSA decryption speed is proportional to (log d)(log n)2 (i.e. quadratic in the length of the modulus, and linear in the length of the private exponent). Similarly, the RSA encryption speed is proportional to (log e)(log n)2. The private key holder also knows the factorization of n, which can be used to speed up private key operation by a factor of about 4 (with the Chinese Remainder Theorem). For details on the involved algorithms, see the Handbook of Applied Cryptography, especially chapter 14 ("Efficient Implementation").
For proper security, the private exponent (d) must be big; it has been shown that if it is smaller than 29% of the length of the modulus (n) then the private key can be reconstructed. We do not know what is the minimum length to avoid such weaknesses, so in practice d will have about the same length than n. This means that decryption will be about cubic in the length of n.
The same provisions do not apply to the public exponent (e), which can be as small as wished for, as long as it complies with the RSA rules (e must be relatively prime to r-1 for all prime factors r of n). So it is customary that a very small e is chosen. It is so customary that there are widely deployed implementations that cannot handle big public exponents. For instance, the RSA implementation in Windows' CryptoAPI (the one used e.g. by Internet Explorer when connected to a HTTPS site with a RSA server certificate) cannot process a RSA public key if e does not fit in 32 bits. e=3 is the best possible, but e=65537 is traditional (it is an historical kind of blunder, because a very small exponent can induce a perceived weakness if RSA is used without its proper and standard padding, something which should never be done anyway). 65537 is a 17-bit long integer, whereas a typical length for n and d will be 1024 bits or more. This makes public-key operations (message encryption, signature verification) much faster than private-key operations (message decryption, signature generation).
In theory, it doesn't have to be. The encryption and decryption algorithms are essentially identical. Given:
d = decryption key
e = encryption key
n = modulus (product of primes)
c = encrypted code group
m = plaintext code group
Then:
Encryption ci = mie (mod n)
Decryption mi = cid (mod n)
The normal algorithm for raising to a power is iterative, so the time taken depends on the size of the exponent. In most cases, the pair works out with the decryption key being (usually considerably) larger than the encryption key.
It is possible to reverse that though. Just for a toy example, consider:
p=17
q=23
n=391
Here's a list of some valid encryption/decryption key pairs for this particular pair of primes:
e = 17, d = 145
e = 19, d = 315
e = 21, d = 285
e = 23, d = 199
e = 25, d = 169
e = 27, d = 339
e = 29, d = 85
e = 31, d = 159
e = 35, d = 171
e = 37, d = 333
e = 39, d = 343
e = 41, d = 249
e = 43, d = 131
e = 45, d = 133
e = 47, d = 15
e = 49, d = 273
e = 51, d = 283
e = 53, d = 93
e = 57, d = 105
e = 59, d = 179
Out of those 20 key pairs, only one has a decryption key smaller than the encryption key. In the other cases, the decryption key ranges from just under twice as big to almost 17 times as large. Of course, when the modulus is tiny like this, it's quick and easy to generate a lot of key pairs, so finding a small decryption key would be fairly easy -- with a real RSA key, however, it's not quite so trivial, and we generally just accept the first pair we find. As you can see from the list above, in that case, you're quite likely to end up with a decryption key that's considerably larger than your encryption key, and therefore decryption will end up slower than encryption. When working with ~100 digit numbers, we'd have to be quite patient to find a pair for which decryption was going to be (even close to) as fast as encryption.
The encryption power is usually chosen to be a prime of the form 2^n+1 (17, 63357) which requires a relatively few multiplication operations. The decryption value will be a much larger number as a consequence, and thus take more work to compute.
There are two factors involved in this:
On the one hand, the public exponent can be chosen to be a small number with only two 1-bits (usually 3, 17 or 65537). This means the RSA encryption operation can be done with a few modular squarings and an addition. This cannot be reversed: If you force the private exponent to be a small number, the security of the system is obviously broken.
On the other hand, the holder of the private key can store some precalculated values derived from the original primes. With those he can use the CRT algorithm to replace the single exponentiation modulo a n-bit number with two exponentiaions modulo a n/2-bit number. This is approximately four times faster than the naive way.
So for RSA key pairs with random public exponents, private key operations can actually be faster. But the effect of choosing a small public exponent is much greater than the effect of the faster algorithm, so encryption is faster in practice.
RSA Laboratories describes why pretty well
In practical applications, it is common to choose a small public exponent for the public key.
...
With the typical modular exponentiation algorithms used to implement the RSA algorithm, public key operations take O(k^2) steps, private key operations take O(k^3) steps
How much longer? Do you have any exact details?
Any way, it make sense that decryption is complicated more than encryption, since the encryption it is not in a symmetric way like 123 => abc and abc > 123.
For more details I suggest starting here.
To read about how the calculatio works, this article seems very good one http://www.di-mgt.com.au/rsa_alg.html
In short "multiply = easy, factor = hard".
Take a look at (http://en.wikipedia.org/wiki/RSA#Encryption) which references optimizations in exponentiation (http://en.wikipedia.org/wiki/Exponentiation_by_squaring#Further_applications)
The best resource I found was the following lecture on cryptography from Princeton (http://www.cs.princeton.edu/courses/archive/spr05/cos126/lectures/22.pdf)
d and e are multiplicatively inverse numbers modulo phi(n). That means that it doesn't matter witch of the two you'll choose for encryption, and witch one for decryption. You just choose once before encryption. If you want fast decryption than you choose the bigger number for encryption. It's that simple.