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.
Related
I am new in cryptography. I need to encrypt a text using AES with some configuration
Encryption mode: GCM
Key size: 256 bits
Nonce size: 96 bits
MAC size: 128 bits
As AES is a symmetric algo. so i have a secrete key. I googled and found
nonce is a random number used to make sure a message is unique
But i have a doubt, how i can perform decryption, if nonce is a random number. do i need to store nonce along with each encryption. or any other way i need to split nonce, cipher and mac using key.
how can i use the provided configuration for encryption.
But i have a doubt, how i can perform decryption, if nonce is a random number. do i need to store nonce along with each encryption.
Yes, result of the encryption stored/sent is nonce, ciphertext, mac.
how i can perform decryption, if nonce is a random number
Nonce is randomly generated when encrypting the input and the nonce is then passed along the ciphertext (very often the nonce is prepended as the first block). Indeed you need THE SAME nonce value when decrypting, then the nonce is part of the input for decrpytion, not random
or any other way i need to split nonce, cipher and mac using key. how can i use the provided configuration for encryption.
There is a standardized message format for encrypted document or encrypted XML messages, but these are pretty pretty complex.
In reality - for simpler applications very often we see the encryption output composed as IV || ciphertext || MAC (as concatenation). IV and MAC are having fixed length, so you can cut them out and use the parameters for decryption.
decryption is happening on different machine and language. they have shared only a key for encryption. same key they are using for decryption. if i will add any random value as nonce then how hey will know what logic i have used for nonc
It doesn't matter until you provide the same input. As already mentioned - you may pass the IV (nonce) as part of the message and before decryption separate the nonce and original ciphertext.
BTW: I have a few encryption examples linked
Precisely, the nonce must be stored with the cipher text.
Remember, the nonce being part of the cipher text doesn't give the attacker any advantage.
From Wikipedia:
An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. However, in most cases, it is important that an initialization vector is never reused under the same key. For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages.
The purpose of initialization vector is to insert some randomness the encryption process so that an attacker cannot know when two identical plaintext messages have been encrypted with the same key.
IV is required for decryption, you can simply send it concatenated with the ciphertext.
IV || ciphertext
The most common way to transmit an initialization vector is, indeed, to prepend it immediately before the ciphertext.
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...
Is it insecure to use the same key and initialization vector in multiple encryption calls? Specifically with regards to AES-CBC, if I had multiple 8kB chunks, and I tried encrypting each chunk separately (essentially resetting the ciphertext XOR block each time), does this lead to insecure encryption?
I know that ECB mode has this issue since each blocksize in the plaintext will be outputted to the same ciphertext. But with 8kB chunks, am I subject to the same issues / are there other security holes that I'm not considering?
Thanks
Yes, it is potentially insecure. The purpose of generating a new, random IV for every encryption is that it ensures that encrypting the same plaintext with the same key results in different ciphertexts each time.
If there's any possibility that the blocks you're encrypting are likely to be the same, then using the same key and IV for encryption will result in revealing to an attacker that you're sending the same data multiple times.
When a user chooses a key how is that key turned into a cipher (either block or stream cipher) to encrypt the data with.
It isn't turned into a cipher. It is used as input of the algorithm of the cipher. Mostly there is some kind of sub-key derivation internally (expanding the key size to create a larger internal state), which is then used to perform e.g. addition, xorring and the like on the data, until you cannot retrieve the orginal data without the key. The cipher itself never changes, only the internal state does.
It depends on the cipher. Read the specification for whatever cipher you're working with. See e.g. http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Description_of_the_cipher or http://en.wikipedia.org/wiki/RC4 .
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.