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.
Related
I am using node and the crypto module to encrypt and decrypt a large binary file. I encrypt the file using crypto.createCipheriv and decrypt it using crypto.createDecipheriv.
For the encryption I use a random IV as follows:
const iv = crypto.randomBytes(16);
const encrypt = crypto.createCipheriv('aes-128-cbc', key, iv)
What I don't understand, do I need to pass a random IV for createDecipheriv as well? The SO here says:
The IV needs to be identical for encryption and decryption.
Can the IV be static? And if it can't, is it considered to be a secret? Where would I store the IV? In the payload?
If I use different random IVs for the encryption and decryption, my payload gets decrypted but the first 16 bytes are corrupt. This means, it looks like the IV needs to be the same but from a security perspective there is also not much value as the payload is decrypted except 16 bytes.
Can anyone elaborate what the go-to approach is? Thanks for your help!
The Key+IV pair must never be duplicated on two encryptions using CBC. Doing so leaks information about the first block (in all cases), and is creates duplicate cipher texts (which is a problem if you ever encrypt the same message prefix twice).
So, if your key changes for every encryption, then your IV could be static. But no one does that. They have a key they reuse. So the IV must change.
There is no requirement that it be random. It just shouldn't repeat and it must not be predictable (in cases where the attacker can control the messages). Random is the easiest way to do that. Anything other than random requires a lot of specialized knowledge to get right, so use random.
Reusing a Key+IV pair in CBC weakens the security of the cipher, but does not destroy it, as in CTR. IV reused with CTR can lead to trivial decryptions. In CBC, it generally just leaks information. It's a serious problem, but it is not catastrophic. (Not all insecure configurations are created equal.)
The IV is not a secret. Everyone can know it. So it is typically prepended to the ciphertext.
For security reasons, the IV needs to be chosen to meet cryptographic randomness security requirements (i.e. use crypto.randomBytes( ) in node). This was shown in Phil Rogaway's research paper. The summary is in Figure 1.2 of the paper, which I transcribe here:
CBC (SP 800-38A): An IV-based encryption scheme, the mode is secure as a probabilistic encryption scheme, achieving indistinguishability from random bits, assuming a random IV. Confidentiality is not achieved if the IV is merely a nonce, nor if it is a nonce enciphered under the same key used by the scheme, as the standard incorrectly suggests to do.
The normal way to implement this is to include the IV prepended to the ciphertext. The receiving party extracts the IV and then decrypts the ciphertext. The IV is not a secret, instead it is just used to bring necessary security properties into the mode of operation.
However, be aware that encryption with CBC does not prevent people from tampering with the data. If an attacker fiddles with ciphertext bits within a block, it affects exactly two plaintext blocks, one of which is in a very controlled way.
To make a very long story short, GCM is a better mode to use to prevent such abuses. In that case, you do not need a random IV, but instead you must never let the IV repeat (in cryptography, we call this property a "nonce"). Luke Park gives an example of how to implement it, here. He uses randomness for the nonce, which achieves the nonce property for all practical purposes (unless you are encrypting 2^48 texts, which is crazy large).
But whatever mode you do, you must never repeat an IV for a given key, which is a very common mistake.
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.
Is there exist a ciphering approach such that encrypting and decrypting order is arbitrary? Like using two padlocks on the same lock loop.
That is, if there are two keys (or keypairs) K1, K2, message M, and the cryptogram C is obtained as (for example) C=M*K1*K2 (where * denotes ciphering), then the message M can be retrieved in each of the following ways: 1) M=C*K1*K2, 2) M=C*K2*K1 (here * denotes deciphering).
Obviously, XOR is a trivial candidate. Do any cryptographically strong examples exist?
Take any strong block cipher (e.g. AES) and run it in Output Feedback Mode or Counter Mode.
Since OFB and CTR are essentially just XOR with a cryptographic pseudo-random stream, this will have the property you seek. Just make sure your K1 and K2 are independent.
Also, since OFB and CTR are NIST-approved (and widely-used) block cipher modes, they will be "cryptographically strong" as long as you implement them correctly and use a strong underlying block cipher.
What you ask for is known as a commutative cipher. One application of such ciphers is Shamir's three pass protocol (which is often explained using padlocks).
It is unclear what you mean by "cryptographically strong". I.e. one requirement that is frequently necessary is that an adversary can not learn the message if he learns the encryption of the message with K1, then encryption of the message with K2 and the encryption of the message with both K1 and K2. This requirement is obvious in the case of Shamir's three pass protocol.
It is easy to see that stream ciphers do not satisfy the requirement above. Hence it would misleading to call a stream cipher a "cryptgraphically strong commutative cipher". Equally easy to break under the assumptions above is Rasmus Fabers proposal (which I think is a construction proposed by Bruce Schneier for something a little different).
Strong commutative ciphers can be based for example on modular exponentiation. The Massey-Omura protocol is a great example.
If the size of the cryptogram is not an issue, you can easily construct such a cipher based on any other cipher:
Have the first encryptor generate a random bitmask B1 of size >= M. Encrypt the bitmask with the original cipher and key and transmit this encryption together with B1 ^ M.
Similarly, the next encryptor generate a new random bitmask B2, encrypts it with his key and transmits both encrypted bitmasks and B2^(B1^M). (and so on for N encryptors).
To decrypt, just decrypt each of the bitmasks in any order and xor them onto the masked 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.
I'm by no means a cryptography expert, I have been reading a few questions around Stack Overflow and on Wikipedia but nothing is really 'clear cut' in terms of defining an IV and its usage.
Points I have discovered:
An IV is prepended to a plaintext message in order to strengthen the encryption
The IV is truely random
Each message has its own unique IV
Timestamps and cryptographic hashes are sometimes used instead of random values, but these are considered to be insecure as timestamps can be predicted
One of the weaknesses of WEP (in 802.11) is the fact that the IV will reset after a specific amount of encryptions, thus repeating the IV
I'm sure there are many other points to be made, can anyone think of any other characteristics which I've missed?
An IV is "a public value which impacts the encryption process". The point of the IV is often to "randomize" the input data to avoid leaking information about which input blocks were identical in the plaintext (because identical blocks happen quite a lot in "real-life" data).
Whether the IV is input by pre-pending it or otherwise depends on the algorithm in which it is used. For symmetric encryption with a block cipher in CBC mode, the IV is pre-pended to the encrypted data (CBC uses, for each block, the previous encrypted block; the IV plays the role of the encrypted block -1).
An IV is distinct from a key in that a key is secret whereas the IV needs not be secret; the IV is often transmitted along the encrypted message. Conversely, the IV must be distinct for every message, whereas the key may be reused. Actually, the IV must be distinct for every message encrypted with the same key; if you use a new key for every message then you can use a constant, fixed IV. Note that the IV needs not be secret, but you can keep it secret if you wish. But the sender and the receiver must agree on the IV, and since the IV changes for every message then it can be inconvenient, in some setups, to keep IV secret.
Whether the IV must be uniformly random, or simply non-repeating, depends on the algorithm. CBC requires a random IV. Other modes are less picky, e.g. GCM. You may derive the key and the IV from a "master key", using a proper one-way function. This is what SSL does. It is more tricky that it seems, do not try it at home.
Repeating the IV is one of the numerous sins of WEP.