I have a couple of questions about HTTPS encryption:
What is the bitsize of the keys used? Is it standardised? (I could not find this information searching the web.)
Can the keys generated for the key length start with a zero, or would this key be counted as a n - 1 bit key?
During the initial handshake client and server agree among other things to an algorithm for symetric encryption. Keysize depends on the algorithm, e.g. AES128 is 128 bit, AES256 256 bit, DES 56 bit etc.
The key itself is random, which also means that it can start with 0. If you would restrict the initial bit to 1, you would effectively leave one bit less for the random bits.
Related
I'm trying to decrypt an encrypted h264 I-frame, and I was given a key of length 15, is this even valid?
Should not it be of length 16, so the binary representation would be 128 bits?
If you have a thing you could type on a keyboard, that is not a proper AES key, no matter the length. AES derives its power from the fact that its key is effectively random. Anything you can type on a keyboard in not an effectively random sequence of equivalent length. There are only about 96 characters you can type easily on a Latin-style keyboard. A byte has 256 values. 96^16 is a minuscule fraction of 256^16.
To convert a "password" that a human could type into an effectively random AES key, you need a password-based key derivation function (PBKDF). The most famous and widely available is PBKDF2. There are other excellent PBKDFs including scrypt and Argon2. All of them require a random salt, and all are (in cryptographic terms) very slow to compute.
That said, regarding your framework, it is not possible to guess how they have converted this string into a key. You must consult the documentation or the implementation. There are an unbounded number of ways to convert strings into keys (most of them are terrible, but there are still an unbounded selection to pick from). As Michael Fehr noted they might have done something insecure like padding with zeros. They might also have used a simple hashing function like SHA-256 and either used a 256-bit key or taken the top or bottom 128 bits. Or…almost literally anything else. There is no common practice here. Each encryption system has to document how it is implemented.
(Note that even if you see "AES-128," this is also ambiguous. It can mean "AES with a 128-bit key" or it can mean "AES with a 128-bit block and a key of 128, 192 or 256 bits." While the former meaning is a bit more common, the latter occurs often, for example in Apple documentation, despite being redundant (AES always has a 128-bit block). So even questions like "how long is the key" requires digging into the documentation or the implementation. Cryptography is unfortunately incredibly unstandardized.)
Should not it be of length 16, so the binary representation would be 128 bits?
You are right. For AES only key length of 128, 192 or 256 bit is valid.
I commonly see two possibilities for having a key of different length:
You was given a password, not a key. Then you need as well to ask for a way to generate a key from the password (Hash? PBKDF2? Other?)
Many frameworks will silently accept different key length and then trim or zero-pad the value to fit the required key size. IMHO this is not a proper approach as it gives the developers feeling the key is good and in reality a different (padded or trimmed) value is used.
I know that DES has a key length of 56, but what does the EDE mean and does it effect the key length?
In OpenSSL there is the des-ede-cbc option.
Triple DES, DES-EDE or TDEA (formally speaking) can be used with no less than 3 key sizes.
The most logical form uses 3 separate keys for each of the phases (Encrypt, Decrypt and then Encrypt again, which is the meaning of EDE). It has a key size of 3 times 56 bits or 168 bits, but those are usually encoded with parity bits (the least significant bit of each byte), making 192 bits in total. Due to a meet-in-the-middle attack (already known at the design phase) the security is only around 112 bits, so don't be fooled by the key size alone. Generally we aim for 128 bit or higher security. This is sometimes DES-ABC - as in DES with distinct keys A, B and C.
The two key DES-EDE uses the same keys for the Encrypt phases. The key size is therefore 112 bits, encoded as 128 bits and a security of just around 80 bits, due to various attacks. For some attacks it might even be reduced to just over 63 bits. 80 bits is probably just a bit on the short side nowadays and it isn't recommended by NIST anymore. It is called the ABA key scheme, and technically you'd use BAB for decryption.
Finally single key DES-EDE is mainly used for backwards compatibility. The first encrypt and decrypt (or decrypt and second encrypt) cancel each other out so you're left with just one encrypt. You can guess the key size: 56 bits. Single DES can be easily brute forced, especially when hardware support is used. Single key TDES is never used in software and may not be supported (it just makes sense in hardware, where you don't want to supply a separate implementation of DES in addition to DES-EDE). I guess you'd call the key scheme AAA, but I haven't seen that name around at all.
DES-EDE is much slower than a good implementation of AES, and AES has a security of around 126,8 for a key size of 128 bits (using a very complicated attack). So if you have any chance, choose AES instead. AES has other advantages as well, such as the larger block size and lack of weak keys.
I came across this:
I don't understand how AES128 is stronger than AES256 in a brute force attack, or how AES256 allows for more combinations than AES128.
These are my simplified premises - assuming I have 100 unique characters on my keyboard, and my ideal password length is 10 characters - there would be 100^10 (or 1x10^20) combinations for brute force attack to decry-pt a given cipher text.
In that case, whether or not AES128 or AES256 is applied doesn't make a difference - please correct me.
Yes, you are correct (in that a weak password will negate the difference between AES128 and AES256 and make bruteforcing as complex as the password is). But this applies only to the case when the password is the only source for key generation.
In normal use, AES keys are generated by a "truly" random source and never by a simple pseudorandom generator (like C++ rand());
AES256 is "more secure" than AES128 because it has 256-bit key - that means 2^256 possible keys to bruteforce, as opposed to 2^128 (AES128). The numbers of possible keys are shown in your table as "combinations".
Personally, I use KeePass and passwords of 20 symbols and above.
Using 20-symbol password composed of small+capital letters (26+26), digits (10) and special symbols (around 20) gives (26+26+10+20)^20 = 1.89*10^38 possible combinations - comparable to an AES128 key.
how AES128 is stronger than AES256 in a brute force attack
AES does multiple rounds of transforming each chunk of data, and it uses different portions of the key in these different rounds. The specification for which portions of the key get used when is called the key schedule. The key schedule for 256-bit keys is not as well designed as the key schedule for 128-bit keys. And in recent years there has been substantial progress in turning those design problems into potential attacks on AES 256.This is the basis for advice on key choice.
how AES256 allows for more combinations than AES128
AES256 uses 256 bits, giving you the permissible combination of aroung 2^256, while in case of 128, its 2^128.
These are my simplified premises - assuming I have 100 unique characters on my keyboard, and my ideal password length is 10
characters - there would be 100^10 (or 1x10^20) combinations for brute
force attack to decry-pt a given cipher text.
I am not quite sure what your understanding is, but when you say applying AES128/AES256, you actually encrypt your password into a cipher text.It is encoded information because it contains a form of the original plaintext that is unreadable by a human. It won't just use all the 100unique characters from your keyboard. It uses more than that. So, if you want to get the original password, you must find the key with which it is encrypted. And that gives you the combination figures 2^128 ans 2^256.
I'm in the process of designing an encryption algorithm. The algorithm is symmetric (single key).
How do you measure an algorithms strength in terms of bits? Is the key length the strength of the algorithm?
EDIT:
Lesson 1: Don't design an encryption algorithm, AES and others are
designed and standardized by academics for a reason
Lesson 2: An encryption algorithms strength is not measured in bits, key sizes are. An algorithm's strength is determined by its design. In general, an algorithm using a larger key size is harder to brute-force, and thus stronger.
First of all, is this for anything serious? If it is, stop right now. Don't do it. Designing algorithms is one of the hardest things in the world. Unless you have years and years of experience breaking ciphers, you will not design anything remotely secure.
AES and RSA serve two very different purposes. The difference is more than just signing. RSA is a public key algorithm. We use it for encryption, key exchange, digital signatures. AES is a symmetric block cipher. We use it for bulk encryption. RSA is very slow. AES is very fast. Most modern cryptosystems use a hybrid approach of using RSA for key exchange, and then AES for the bulk encryption.
Typically when we say "128-bit strength", we mean the size of the key. This is incredibly deceptive though, in that there is much more to the strength of an algorithm than the size of it's key. In other words, just because you have a million bit key, it means nothing.
The strength of an algorithm, is defined both in terms of it's key size, as well as it's resistance to cryptanalytic attacks. We say an algorithm is broken if there exists an attack better than brute force.
So, with AES and a 128-bit key, AES is considered "secure" if there is no attack that less than 2^128 work. If there is, we consider it "broken" (in an academic sense). Some of these attacks (for your searching) include differential cryptanalysis, linear cryptanalysis, and related key attacks.
How we brute force an algorithm also depends on it's type. A symmetric block cipher like AES is brute forced by trying every possible key. For RSA though, the size of the key is the size of the modulus. We don't break that by trying every possible key, but rather factoring. So the strength of RSA then is dependent on the current state of number theory. Thus, the size of the key doesn't always tell you it's actual strength. RSA-128 is horribly insecure. Typically RSA key sizes are 1024-bits+.
DES with a 56-bit key is stronger than pretty much EVERY amateur cipher ever designed.
If you are interested in designing algorithms, you should start by breaking other peoples. Bruce Schenier has a self-study course in cryptanalysis that can get you started: http://www.schneier.com/paper-self-study.html
FEAL is one of the most broken ciphers of all time. It makes for a great starting place of learning block cipher cryptanalysis. The source code is available, and there are countless published papers on it, so you can always "look up the answer" if you get stuck.
You can compare key lengths for the same algorithm. Between algorithms it does not make too much sense.
If the algorithm is any good (and it would be very hard to prove that for something homegrown), then it gets more secure with a longer key size. Adding one bit should (again, if the algorithm is good) double the effort it takes to brute-force it (because there are now twice as many possible keys).
The more important point, though, is that this only works for "good" algorithms. If your algorithm is broken (i.e. it can be decrypted without trying all the keys because of some design flaws in it), then making the key longer probably does not help much.
If you tell me you have invented an algorithm with a 1024-bit key, I have no way to judge if that is better or worse than a published 256-bit algorithm (I'd err on the safe side and assume worse).
If you have two algorithms in your competition, telling the judge the key size is not helping them to decide which one is better.
Oh man, this is a really difficult problem. One is for sure - key length shows nothing about encryption algorithm strength.
I can only think of two measures of encryption algorithm strength:
Show your algorithm to professional cryptanalyst. Algorithm strength will be proportional to the time cryptanalyst has taken to break your encryption.
Strong encryption algorithms makes encrypted data look pretty much random. So - measure randomness of your encrypted data. Algorithm strength should be proportional to encrypted data randomness degree. Warning - this criteria is just for playing arround, doesn't shows real encryption scheme strength !
So real measure is first, but with second you can play around for fun.
Assuming the algorithm is sound and that it uses the entire key range...
Raise the number of unique byte values for each key byte to the power of the number of bytes.
So if you are using only ASCII characters A-Z,a-z,0-9, that's 62 unique values - a 10 byte key using these values is 62^10. If you are using all 256 values, 0x00 - 0xFF, a 10 byte key is 256^10 (or 10 * 8 bits per byte = 2 ^ 80).
"Bits of security" is defined by NIST (National Institute of Standards and Technology), in:
NIST SP 800-57 Part 1, section 5.6.1 "Comparable Algorithm Strengths".
Various revisions of SP 800-57 Part 1 from NIST:
http://csrc.nist.gov/publications/PubsSPs.html#800-57-part1
Current version:
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
The "strength" is defined as "the amount of work needed to “break the algorithms”", and 5.6.1 goes on to describe that criterion at some length.
Table 2, in the same section, lays out the "bits of security" achieved by different key sizes of various algorithms, including AES, RSA, and ECC.
Rigorously determining the relative strength of a novel algorithm will require serious work.
My quick and dirty definition is "the number of bits that AES would require to have the same average cracking time". You can use any measure you like for time, like operations, wall time, whatever. If yours takes as long to crack as a theoretical 40-bit AES message would (2^88 less time than 128-bit AES), then it's 40 bits strong, regardless of whether you used 64,000 bit keys.
That's being honest, and honestly is hard to find in the crypto world, of course. For hilarity, compare it to plain RSA keys instead.
Obviously it's in no way hard and fast, and it goes down every time someone finds a better crack, but that's the nature of an arbitrary "strength-in-terms-of-bits" measure. Strength-in-terms-of-operations is a much more concrete measure.
What is the minimum number of bits needed to represent a single character of encrypted text.
eg, if I wanted to encrypt the letter 'a', how many bits would I require. (assume there are many singly encrypted characters using the same key.)
Am I right in thinking that it would be the size of the key. eg 256 bits?
Though the question is somewhat fuzzy, first of all it would depend on whether you use a stream cipher or a block cipher.
For the stream cipher, you would get the same number of bits out that you put in - so the binary logarithm of your input alphabet size would make sense. The block cipher requires input blocks of a fixed size, so you might pad your 'a' with zeroes and encrypt that, effectively having the block size as a minimum, like you already proposed.
I'm afraid all the answers you've had so far are quite wrong! It seems I can't reply to them, but do ask if you need more information on why they are wrong. Here is the correct answer:
About 80 bits.
You need a few bits for the "nonce" (sometimes called the IV). When you encrypt, you combine key, plaintext and nonce to produce the ciphertext, and you must never use the same nonce twice. So how big the nonce needs to be depends on how often you plan on using the same key; if you won't be using the key more than 256 times, you can use an 8 bit nonce. Note that it's only the encrypting side that needs to ensure it doesn't use a nonce twice; the decrypting side only needs to care if it cares about preventing replay attacks.
You need 8 bits for the payload, since that's how many bits of plaintext you have.
Finally, you need about 64 bits for the authentication tag. At this length, an attacker has to try on average 2^63 bogus messages minimum before they get one accepted by the remote end. Do not think that you can do without the authentication tag; this is essential for the security of the whole mode.
Put these together using AES in a chaining mode such as EAX or GCM, and you get 80 bits of ciphertext.
The key size isn't a consideration.
You can have the same number of bits as the plaintext if you use a one-time pad.
This is hard to answer. You should definitely first read up on some fundamentals. You can 'encrypt' an 'a' with a single bit (Huffman encoding-style), and of course you could use more bits too. A number like 256 bits without any context is meaningless.
Here's something to get you started:
Information Theory -- esp. check out Shannon's seminal paper
One Time Pad -- infamous secure, but impractical, encryption scheme
Huffman encoding -- not encryption, but demonstrates the above point