I want to know if data stored in encrypted form is encrypted by block-cipher or a stream-cipher?
I have encrypted data, how do I check that it comes from a block or a stream cipher?
With only the encrypted data, there's no way to tell for sure, but a good indicator is to check the data length.
All of the common modern block ciphers (AES, Blowfish, DES, Serpent, Twofish) have block sizes of either 64 or 128 bits (8 and 16 bytes, respectively). Thus, if the encrypted data length in bytes is a multiple of 8, it's likely to be a block cipher (you have 1 in 8 probability of being wrong). if It's not a multiple of 8, you can be sure it's not a block cipher in common block modes (at most, it's a block cipher trying to emulate a stream cipher, such as in CFB mode).
Don't forget to exclude any potential file/stream headers, IVs, etc. Of course, if you do have a header, you might want to check there first to detect what cipher it's using...
Related
I am trying to implement a SOAP client that's supposed to receive an message (XML) with MTOM/XOP attachment. The message body and attachment are encrypted using separate keys. The encryption algorithm used is AES128-CBC. The body is base64 encoded and decrypts fine, however the attachment is binary and has odd lengths (530 bytes, 527 bytes, etc).
My question is, is it possible that the server is messing something up in encryption? Or is it possible to produce AES128 output that's not multiple of 16?
AES in CBC mode will always produce output that is a multiple of 16 bytes.
If AES is used in CTR (Counter) mode) it produces output with the same length as the input.
AES is a block cipher and works with 16-byte blocks that is 16-bytes of data at a time. For CBC mode the input and output must be a multiple of 16-bytes. CTR mode does not have this requirement.
The way around this is to add padding bytes to the input prior to encryption and remove them after decryption. This can be done automatically by specifying a padding type, generally PKCS#7 padding.
what is differance between stream cipher and block cipher?As in block cipher data are in chucks while in stream cipher bit by bit encrypting so how many data are as input in stream cipher?
The stream in Stream Cipher refers to the key, not the data. In a block cipher, the key encrypts a block of data (typically 8 or 16 bytes) at a time, and normally a Cipher Mode is used to modify the key from block to block. In a stream cipher, some mechanism is used to generate a key stream and the data is then typically only XOR-ed with the key stream. The key stream can be a one-time-pad known beforehand to sender and recipient, or the output of a random number generator with an initial state known to sender and recipient. Even most block ciphers can be used in CTR or OFB mode so they effectively become stream ciphers.
Why would one use a stream cipher? Well, the final operation is a simple XOR, which is very fast. The keystream can be computed independently, even beforehand. Therefore, stream ciphers are popular where encryption in real-time is needed, for example for encrypted telephony.
Why would one not use a stream cipher? Well, the final operation is a simple XOR, which means that regular patterns in the key stream can be exploited by an attacker. Care must be taken to make sure the keystream will never repeat, by using numbers used once and other mechanisms to guarantee uniqueness. With block ciphers, this condition is not as important: while in CBC mode, a random Initialization Vector is preferred, constant IVs are not nearly as dangerous as they are in stream ciphers.
My device doesn't support full 3DES (EDE). How can I emulate one using standard DES? Encryption mode is CBC.
You start by picking three independent DES keys which are not related to each other in any way.
You will want to put DES into ECB mode, not CBC mode. You also need to ensure that each encryption and decryption operation is done only on 64-bit blocks and nothing more or less. Padding schemes and the likes will cause a vulnerability in the implementation and will lead to the discovery of the block content via brute force faster than a brute force against each key.
Using the first key, encrypt your plaintext. Using the second key, decrypt that value. Using the third key, encrypt the value for your full block. It looks like this:
Encrypt(k3, Decrypt(k2, Encrypt(k1, plaintext)))
Decryption is the other way around and looks like this:
Decrypt(k1, Encrypt(k2, Decrypt(k3, ciphertext)))
When you encrypt your blocks with 3DES you then need to apply your mode of operation like CBC or CTR and apply padding if needed.
Be careful.
Block mode encryption
What you do is that you split the key of size 128 bit (16 byte) or 168 bit (24 byte) in two or three pieces respectively. So for a 16 byte key K you would have two keys Ka and Kb, and for a 24 byte key you would have Ka, Kb and Kc. DES ABC keys have an effective strength of about 112 bits, DES ABA keys have an effective strength of about 80 bits.
To encrypt a single block of 8 bytes (the block size of both DES and 3DES) you would perform the following cryptographic operation: Cn = E(Ka, D(Kb, E(Kc, Mn))) where Mn is the n'th block of the plain text message and Cn the n'th block of the cipher text. If you don't have a Kc then you may use Ka (DES ABC key vs DES ABA key).
For this you need a single block DES encrypt, which is identical to a single block encrypt in ECB mode, or a single block encrypt with CBC and an IV consisting of 8 bytes valued 00h.
CBC
So that's the block encryption sorted, now you need some kind of encryption mode and padding mode. I'll explain CBC mode encryption here, ECB should not be used for encryption non-random data.
With CBC mode encryption you XOR a vector to the plain text. The vector is normally just the output of the last DESede encrypted block. As you don't have any preceding cipher text, you need to create the first vector yourself using random data. This vector is called the initialization vector or IV. See wikipedia for a clear picture.
Padding
Block cipher modes only allow full blocks of plain text to be encrypted. So you would need some kind of padding scheme. Although there are many padding modes, PKCS#5 padding is used most of the time. You should pad the plain text like this: pad with bytes valued 0Xh, where X is the number of padding bytes required to create a full block. X should be between 1 and 8: in other words, PKCS#5 padding is always used; this makes it possible to distinquish the padding bytes from the plain text.
If you use padding in an online protocol then you need to protect against padding oracle attacks. In this case it is highly recommended to use some form of integrity checks, e.g. by adding a HMAC over the cipher text using a separate key.
3DES is just DES used three times on the plaintext:
ciphertext = E_K3(D_K2(E_K1(plaintext)))
plaintext = D_K1(E_K2(D_K3(ciphertext)))
E_Kn = Encryption with Key number n.
D_Kn = Decryption with Key number n.
So you can easily "emulate" 3DES with just DES.
In CBC mode you'll need an IV to start with and then XOR the next plaintext block with the previous ciphertext block. If your device doesn't support CBC then this too is easily "emulated".
I understand that block ciphers are more popular in software as opposed to stream ciphers which are typically hardware based. However, why can't a key be reused in stream ciphers? Is it because of patterns that may form?
A stream cipher is an encryption system which works over a given sequence of input bits. Most stream ciphers work by generating from the key a long sequence of random-looking bits, which are then combined (by bitwise XOR) with the data to encrypt. This is a (crude) emulation of one-time pad.
A block cipher is a generic cryptographic element which works over "blocks" which are sequences of bits with a fixed length (e.g. 128 bits for AES). The block cipher is a permutation of the blocks; the key selects which permutation we are talking about. A block cipher alone cannot process an arbitrary long message; the block cipher and the data must be used within an elaborate construction called a mode of operation (also often called a "chaining mode").
There is a chaining mode for block ciphers called "CTR" as "counter mode": in this mode, the block cipher is used to encrypt successive values of a counter (the counter having the size of a block). The resulting encrypted blocks are then concatenated, resulting in an arbitrarily long sequence of bits which depend only on the key. It suffices then to XOR that sequence with the data to encrypt. In other words, CTR mode turns a block cipher into a stream cipher. Another popular chaining mode is CBC, which does not fit the model of a stream cipher.
With stream ciphers, what must be avoided at all costs is reusing the same key-dependent sequence of bits for two distinct messages; this would yield the infamous "two-times pad" which can be broken quite easily (by exploiting redundancies in the two encrypted messages). With a block cipher in CTR mode, this translates to reusing the same counter values. This is why CTR mode requires a random Initial Value (IV) which is the counter value you begin encryption with. By choosing a new random IV, with sufficiently large blocks, you avoid with very high probability any overlap in the sequences of counter values that you use.
The concept of IV is not specific to block ciphers; some stream ciphers also use an IV (e.g. the one in the eSTREAM portfolio). When a stream cipher has an IV, reusing the key is no problem -- provided that you use proper IV (i.e. IV generated with a cryptographically strong RNG in the complete space of possible IV, with uniform probability). However, some other stream ciphers do not have an IV, in particular the widely used RC4. Reusing the same key would mean reusing the exact same sequence of generated bits, and that's bad.
Note that some chaining modes other than CTR also need an IV, which should be unique for each message encrypted with a given key. Block ciphers do not alleviate the need for that.
because when reusing the key in stream cipher the stream cipher
general function is encryption=(plaintext+key)%2
and modulo 2 is considered xor
so reusing the key for encryption function will cause the cipher text to repeat it self after some length
so a random generators are used to produce key every time in the encryption operation
like LFSR to produce random key every time
one time pad is also used
Block cipher: Block cipher is like encrypting a message block by block.
It's breaking the block by block then after encryption of the message.
Stream cipher: Stream cipher is like a bit by bit encryption of the original message.
I checked out TripleDES. It's block size is of 64 bits.
Is there any algorithm for 8 bits block size?
Thanks
EDIT : I intend not to use this for perfect protection, but for a just-in-case situation where one who sees the code should not find the plaintext. So 8 bit is kinda okay for me.
A block cipher with 8-bit blocks means that each input block can be encrypted into 256 possible values -- which means that an attacker has a 1/256 chance of guessing the input value. It turns out to be very difficult to use such an algorithm securely. Nevertheless it is possible to define a block cipher over 8-bit blocks, and to do it "perfectly"; just do not expect it to be generally useful.
There also are "block-less" ciphers, known as "stream ciphers" which encrypt data "byte by byte" (or even "bit by bit"); most are just pseudo-random generators which produce an arbitrary amount of bytes from a key. That generated stream is just to be combined with the data to encrypt with a XOR. The traditional stream cipher is RC4; but newer and better stream ciphers have been designed.
A block cipher, by itself, is a mathematical tool. In order to actually encrypt data, the block cipher must be used properly. The keywords are chaining and padding. Chaining is about defining what actually goes into the block cipher and what to do with the output. Padding is about adding some bytes to the data, in a reversible way, so that the padded message length is appropriate for the chosen chaining mode. The traditional chaining mode is called CBC. A newer (and arguably better) chaining mode is CTR (same link), which has the added bonus of avoiding the need for padding (CTR just turns a block cipher into a stream cipher).
As for block ciphers, you should use AES instead of TripleDES. It is faster, more secure, and the current American standard.
RSA with 8-bit key :)
Seriously though, the block-based cyphers are stateless - the ciphertext of a block depends only on the cleartext of the block, not on the previous blocks (otherwise it would be a stream cypher). A block cypher that acts on 8-bit blocks can be brute-forced easily, so there's no point.