Blog

Categories:

4. 5. 2026

Security Cryptography

Key size and comparison of security protection

How to compare the security of cryptographic algorithms with different key sizes?

Most administrators are concerned with the largest possible keys that will guarantee security. But if they need to deal with the relationship between key sizes (key material), the comparison is difficult for them. What is better? How to compare a 128b key for symmetric ciphers with 4096b RSA? What should be more secure? Or the current question, how to compare the strength of classical and quantum-resistant algorithms? What affects the evaluation?

Complexity and security equivalent

Until the advent of quantum computers, mathematics clearly dictated the minimum key sizes to us in roughly the following way. Based on the properties of the algorithm or the best known attack, the total complexity, expressed as the number of operations, was calculated. Since this complexity is expressed as a power of two, the exponent is an expression of the security equivalent and security.

Why is algorithm complexity not enough?

If this output is compared with the official recommendations, there are some minor differences. These are given by the algorithm architecture, implementation, specific properties of the algorithm and, if applicable, a safety margin. These are precisely the reasons that lead to an approximately 20% - 30% increase in the required key size for asymmetric algorithms, as stated in the documentation of BSI, ECRYPT, NIST, NUKIB and others. And this is also the reason why it is advisable to follow such advice. Relying solely on complexity can be shortsighted, and especially for asymmetric algorithms, it may not fully reflect reality.

Key width requirements by problem complexity

Security equivalent	RSA (bits)	DLP-MG (bits)	DLP-AG (bits)	Hash (bits)	Symmetric algorithms (bits)
64	355	600	129	128	64
92	812	1392	185	184	92
112	1284	2218	225	224	112
128	1758	3052	257	256	128
160	2993	5234	321	320	160
192	4648	8173	385	384	192
224	6766	11949	449	448	224
256	9389	16642	513	512	256
384	25715	46029	769	768	384
512	53100	95636	1025	1024	512

The above table shows at first glance how the RSA algorithm, based on factorization, performed. In the case of the DLP-MG column (discrete logarithm problem over multiplicative group), this covers the Diffie-Hellman algorithm, but also applies to the ElGamal algorithm, the Schnorr signature, and the DSA algorithm. The next column is DLP-AG (discrete logarithm problem over additive group). This includes algorithms such as ECDH, ECDSA, and EDDSA. Next are hashes sorted by output width, and finally symmetric algorithms, under which block and stream algorithms such as AES, CHACHA20, and others can be classified. For symmetric algorithms, only the influence of the key length is considered.

The change caused by quantum computers

The arrival of quantum computers changes everything. The original idea of security has taken its toll, most algorithms have been taken by the ears in terms of security, as they say. Current asymmetric algorithms should be broken by Shor's algorithm, while Grover's algorithm is a threat to symmetric algorithms with small key widths. For this reason, it makes no sense to discuss the asymmetric algorithms in the previous table (RSA, Diffie-Hellman, ElGamal, Schnorr signature, DSA, ECDH, ECDSA and EDDSA), because the complexity of the attack is extremely low. Such an attack would take place in the case of a cryptographically relevant quantum computer in the order of minutes to hours. On the other hand, new algorithms are emerging that are ready to withstand these attacks. The first overview therefore describes how the security of hash functions with a certain output width and similarly symmetric algorithms with a specific key length will change.

Historical context

Key width as such may not be sufficient protection in the future. The current situation somewhat reminds me of the situation with the DES and 3DES algorithms. In the years 1995-2000, due to the increasing data volumes, the risks of algorithms with a block size of 64 bits were considered. In order to protect against some attacks, a double or triple key width was used as a temporary solution. Therefore, two variants of the 3DES algorithm were created, where the first performed encryption using three separate keys (Enc k1, Enc k2, Enc k3), the second used only two keys and worked in EDE mode (Enc k1, Dec k2, Enc k1). Fortunately, Groover's attack cannot currently be used in this way. Unfortunately, there is a similar algorithm called Brassard–Høyer–Tapp. It is designed to solve this problem. Fortunately, its demand for quantum memory is so high that it will not be possible to satisfy it in the coming decades. Unlike this algorithm, Groover's algorithm practically does not require any memory. However, if in the future an attack is found where the BHT algorithm does not need memory, we will have serious problems.

Security equivalent of symmetric algorithms on quantum computers

Security equivalent	Hash functions (bits)	Symmetric algorithms (bits)
32	128	64
64	184	128
92	224	184
128	256	256
160	320	320
192	384	384
224	448	448
256	512	512
384	768	768
512	1024	1024

The table shows the change in the difficulty of attacking quantum computers compared to digital computers (previous tables). In order to ensure adequate security, it is necessary to double the width of the hash function output, and the key material entering symmetric algorithms must also be twice as large.

Upcoming algorithms resistant to quantum computers

Upcoming algorithms resistant to attacks using quantum computers (PQC/QRC) can help solve the problem with asymmetric algorithms. These are mainly sets standardized by IETF and NIST. The following note needs to be added to this. Sometimes you can come across the term quantum algorithms, which refers to attacks using Groover's and Shor's algorithms. These are not algorithms designed for encryption on quantum computers. Similarly, quantum cryptography is not a matter of algorithms for encryption on quantum computers, but of securing transmissions using quantum phenomena. These, under specific conditions, protect the communication channel from eavesdropping or message modification.

New standardized algorithms are based on various approaches. On the one hand, there are algorithms built on lattices, linear codes, systems of quadratic equations with multiple unknowns, supersingular curves and hash trees. There are other interesting problems, but for them either practically there are no algorithms,because they were found to be insufficient. At this point, we have, thanks to NIST, standardized algorithms ML-KEM, ML-DSA, FN-DSA, and FN-DSA are being prepared for standardization. The IETF proposes XMSS, XMSS-MT, and LMS. There are a large number of comparisons of these asymmetric algorithms with classical ones, and often the comparisons are completely meaningless. This criterion must not be guided by the key width, but only by the security equivalent. Using key width is a misunderstanding of the differences between algorithms and the causes that lie in the problem of complexity.

Security equivalent	Security level	Description
128 bits	Security level 1	AES-128, exhaustive key search
128 bits	Security level 2	SHA-256, collision search
192 bits	Security level 3	AES-192, exhaustive key search
192 bits	Security level 4	SHA-384, collision search
256 bits	Security level 5	AES-256, exhaustive key search

According to the above overview, it is possible to translate the corresponding security equivalent for example, to the RSA algorithm. This means the need to use the corresponding complexity and resistance of the algorithms, not the length of the private key. The meaning of such a comparison would be meaningless.

Key agreement

As part of the standardization of PQC algorithms, the FIPS-203 ML-KEM standard (originally CRYSTALS Kyber) was created. Also currently in the process of standardization is FIPS-207 HQC-KEM (HQC algorithm).

Algorithm	Security level	Private key (bits)	Public key (bits)
ML-KEM-512	1	6400	13056
ML-KEM-768	2	9472	19200
ML-KEM-1024	3	12544	25344
HQC-128	1	448	19272
HQC-192	2	512	36808
HQC-256	3	576	57960

Digital Signature Algorithms

As part of the standardization of PQC algorithms, the FIPS-204 ML-DSA (originally CRYSTALS Dilithium) and FIPS-205 SLH-DSA (SPHINCS+) standards have been created. Furthermore, the FIPS-206 FN-DSA (originally Falcon) is currently in the process of being standardized. Other algorithms for the second round are in the selection phase.

Algorithm	Security level	Private key (bits)	Public key (bits)
ML-DSA-44	1	20480	10496
ML-DSA-65	2	22256	15616
ML-DSA-87	3	39168	20736
SLH-DSA-128	1	512	256
SLH-DSA-192	2	512	256
SLH-DSA-256	3	512	256
FN-DSA-512	1	10248	7176
FN-DSA-768	2	14856	10760
FN-DSA-1024	3	18440	14344

In addition to the algorithms standardized by NIST, algorithms for digital signatures have also been created and standardized within the IETF. This table is not a complete list of all their variants.

Algorithm	Security level	Private key	Public key (bits)
LMS-128	1	By tree size	256
XMSS-128	1	By tree size	256
XMSS-192	2	By tree size	256
XMSS-256	3	By tree size	256
XMSSMT-128	1	By tree size	256
XMSSMT-192	2	By tree size	256
XMSSMT-256	3	By tree size	256

Too expensive direct heaters

The same is true with the implementation of technologies using cryptographic algorithms. The level of resistance of all algorithms protecting data should be similar. Significant deviations can cause unnecessarily high overhead in some areas (key agreement, integrity, confidentiality, authentication). Unnecessary overuse of resources generates heat, at which point overpriced direct heaters are created instead of data protection. It is therefore appropriate for all components to use approximately the same security equivalent, and its strengthening in certain areas should be supported by a developed risk analysis.

Conclusion

Comparing the incomparable is the most common problem of changes brought about by the transition to quantum resistant cryptography. The imbalance of algorithms in terms of security equivalent or insufficient strength of protection using encryption technologies has a similar effect. The above approaches can compromise data, especially ensuring its confidentiality and integrity.

References:

RFC 8391: XMSS: eXtended Merkle Signature Scheme.
Source: https://www.rfc-editor.org/
RFC 8554: Leighton-Micali Hash-Based Signatures.
Source: https://www.rfc-editor.org/
FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard.
Source: https://www.nist.gov/
FIPS 204 Module-Lattice-Based Digital Signature Standard.
Source: https://www.nist.gov/
FIPS 205 Stateless Hash-Based Digital Signature Standard.
Source: https://www.nist.gov/
FIPS 206 Fiat–Naor Digital Signature Algorithm (standardization in progress).
Source: https://www.nist.gov/
FIPS 207 Hamming Quasi-Cyclic Key Exchange Mechanism (standardization in progress).
Source: https://www.nist.gov/

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.

1. Introductory Provisions

1.1. These General Terms and Conditions are, unless otherwise agreed in writing in the contract, an integral part of all contracts relating to training organised or provided by the trainer, Jan Dušátko, IČ 434 797 66, DIČ 7208253041, with location Pod Harfou 938/58, Praha 9 (next as a „lector“).
1.2. The contracting parties in the general terms and conditions are meant to be the trainer and the ordering party, where the ordering party may also be the mediator of the contractual relationship.
1.3. Issues that are not regulated by these terms and conditions are dealt with according to the Czech Civil Code, i.e. Act No.89/2012 Coll.
1.4. All potential disputes will be resolved according to the law of the Czech Republic.

2. Creation of a contract by signing up for a course

2.1. Application means unilateral action of the client addressed to the trainer through a data box with identification euxesuf, e-mailu with address register@cryptosession.cz or register@cryptosession.info, internet pages cryptosession.cz, cryptosession.info or contact phone +420 602 427 840.
2.2. By submitting the application, the Client agrees with these General Terms and Conditions and declares that he has become acquainted with them.
2.3. The application is deemed to have been received at the time of confirmation (within 2 working days by default) by the trainer or intermediary. This confirmation is sent to the data box or to the contact e-mail.
2.4. The standard time for registration is no later than 14 working days before the educational event, unless otherwise stated. In the case of a natural non-business person, the order must be at least 28 working days before the educational event.
2.5. More than one participant can be registered for one application.
2.6. If there are more than 10 participants from one Client, it is possible to arrange for training at the place of residence of the intermediary or the Client.
2.7. Applications are received and processed in the order in which they have been received by the Provider. The Provider immediately informs the Client of all facts. These are the filling of capacity, too low number of participants, or any other serious reason, such as a lecturer's illness or force majeure. In this case, the Client will be offered a new term or participation in another educational event. In the event that the ordering party does not agree to move or participate in another educational event offered, the provider will refund the participation fee. The lack of participants is notified to the ordering party at least 14 days before the start of the planned term.
2.8. The contract between the provider and the ordering party arises by sending a confirmation from the provider to the ordering party.
2.9. The contract may be changed or cancelled only if the legal prerequisites are met and only in writing.

3. Termination of the contract by cancellation of the application

3.1. The application may be cancelled by the ordering party via e-mail or via a data mailbox.
3.2. The customer has the right to cancel his or her application for the course 14 days before the course takes place without any fees. If the period is shorter, the subsequent change takes place. In the interval of 7-13 days, an administrative fee of 10% is charged, cancellation of participation in a shorter interval than 7 days then a fee of 25%. In case of cancellation of the application or order by the customer, the possibility of the customer's participation in an alternative period without any additional fee is offered. The right to cancel the application expires with the implementation of the ordered training.
3.3. In case of cancellation of the application by the trainer, the ordering party is entitled to a full refund for the unrealized action.
3.4. The ordering party has the right to request an alternative date or an alternative training. In such case, the ordering party will be informed about all open courses. The alternative date cannot be enforced or enforced, it depends on the current availability of the course. If the alternative training is for a lower price, the ordering party will pay the difference. If the alternative training is for a lower price, the trainer will return the difference in the training prices to the ordering party.

4. Price and payment terms

4.1. By sending the application, the ordering party accepts the contract price (hereinafter referred to as the participation fee) indicated for the course.
4.2. In case of multiple participants registered with one application, a discount is possible.
4.3. The participation fee must be paid into the bank account of the company held with the company Komerční banka č. 78-7768770207/0100, IBAN:CZ5301000000787768770207, BIC:KOMBCZPPXXX. When making the payment, a variable symbol must be provided, which is indicated on the invoice sent to the client by the trainer.
4.4. The participation fee includes the provider's costs, including the training materials. The provider is a VAT payer.
4.5. The client is obliged to pay the participation fee within 14 working days of receipt of the invoice, unless otherwise stated by a separate contract.
4.6. If the person enrolled does not attend the training and no other agreement has been made, his or her absence is considered a cancellation application at an interval of less than 7 days, i.e. the trainer is entitled to a reward of 25% of the course price. The overpayment is returned within 14 days to the sender's payment account from which the funds were sent. Payment to another account number is not possible.
4.7. An invoice will be issued by the trainer no later than 5 working days from the beginning of the training, which will be sent by e-mail or data box as agreed.

5. Training conditions

5.1. The trainer is obliged to inform the client 14 days in advance of the location and time of the training, including the start and end dates of the daily programme.
5.2. If the client is not a student of the course, he is obliged to ensure the distribution of this information to the end participants. The trainer is not responsible for failure to comply with these terms and conditions.
5.2. By default, the training takes place from 9 a.m. to 5 p.m. at a predetermined location.
5.3. The trainer can be available from 8 a.m. to 9 a.m. and then from 17 a.m. to 6 p.m. for questions from the participants, according to the current terms and conditions.
5.4. At the end of the training, the certificate of absorption is handed over to the end users.
5.5. At the end of the training, the end users evaluate the trainer's approach and are asked to comment on the evaluation of his presentation, the manner of presentation and the significance of the information provided.

6. Complaints

6.1. If the participant is grossly dissatisfied with the course, the trainer is informed of this information.
6.2. The reasons for dissatisfaction are recorded in the minutes in two copies on the same day. One is handed over to the client and one is held by the trainer.
6.3. A statement on the complaint will be submitted by e-mail within two weeks. A solution will then be agreed within one week.
6.4. The customer's dissatisfaction may be a reason for discontinuing further cooperation, or financial compensation up to the price of the training, after deduction of costs.

7. Copyright of the provided materials

7.1. The training materials provided by the trainer in the course of the training meet the characteristics of a copyrighted work in accordance with Czech Act No 121/2000 Coll.
7.2. None of the training materials or any part thereof may be further processed, reproduced, distributed or used for further presentations or training in any way without the prior written consent of the trainer.

8. Liability

8.1. The trainer does not assume responsibility for any shortcomings in the services of any third party that he uses in the training.
8.2. The trainer does not assume responsibility for injuries, damages and losses incurred by the participants in the training events or caused by the participants. Such costs, caused by the above circumstances, shall be borne exclusively by the participant in the training event.

9. Validity of the Terms

9.1 These General Terms and Conditions shall be valid and effective from 1 October 2024.