Blog

Impacts of migration to PQC

The transition to quantum computer-resistant algorithms

The only constant feature of the world is change. Even in cryptography, after a period of apparent calm, paradigm shifts occur, bringing a new perspective and sending previous technologies to the dustbin of history. This can result in a replacement of technologies as such, usually meaning classical development. Or an earthquake caused by a complete replacement with no chance of a gradual generational replacement, in which case it is necessary to simply start over.

Why is this transition necessary?

Currently, so-called quantum computers are coming on the scene. Current cryptography has problems with them. The reason is simple. Previously theoretical procedures, requiring the energy output of the entire galaxy to break current algorithms, or time far beyond the lifetime of the universe, have been incredibly reduced by quantum computers. The new approach means power in the tens to hundreds of kW over a period in the orders of units up to tens of days. Moreover, today it is possible to capture existing secrets, which can be broken only after a few years. And their impact can be devastating for a given organization.
Thanks to these procedures, it is possible to break current algorithms, which ensure confidence in data protection by means of methods such as digital signature, key material exchange, or key agreement. With symmetric algorithms, the situation is similar, though not as urgent. Here, too, a change will be necessary, most often consisting in increasing the length of the key (and eventually in increasing the length of the block). Both these directions are thus awaiting a change, built on new concepts of the approach. Currently, these procedures are called PQC (Post-Quntum Cryptography), or post-quantum cryptography. In addition to this name, it is possible to occasionally encounter QRC (Quantum Resistant Cryptography), a quantum-resistant cryptography, in which case it is probably meant quantum computing or quantum computers.

What does the transition involve?

Although this does not seem to be a big problem, the transition to quantum-computer-resistant cryptography will mean significant changes in architecture, changes in system settings in terms of cryptography support, and large-scale investments. A very cursory look at these changes is not enough, it can lead to erroneous conclusions. At first glance, these are only changes to the encryption of the transport layer, known as SSL/TLS. Changing algorithms only means changing the encryption sets, everyone can do that. But outside of SSL/TLS, this also means changing other places. Another communication channel is SSH, it also uses encryption to protect transmission. These are VPN technologies based on the principles of SSL/TLS, IPSec, OpenVPN, WireGuard, but also SSTP as a replacement (better encapsulation) for PPTP. But it does not stop there.
Technologies such as SSL/TLS, IPSec, OpenVPN, SSTP and others require a change even at the level of certificates. These provide proof of verifiability, unfortunately they use obsolete algorithms. Again, from the PQC point of view, these mechanisms need to be changed. This means changing the whole structure of PKI (Public Key Infrastructure). Here we are already talking about significant costs, infrastructure change and other impacts. But this is just the beginning of the whole issue. Because both transport encryption and VPN networks and the structure of PKI depend on the secure structure of the Internet. This brings us to the basic services of the Internet and communication.
One of the basic protocols is provided by the Domain Name System service, otherwise also the service of name translation. This has long been criticized because of the minimal protection of transmitted data, and as a solution, the extension of DNSSEC has been offered for several years (I don't forgive noting here that this extension is still little used). This has the ability to provide proof of correctness again, this time in the form of a digitally signed response with name translation. Based on current knowledge, it is not possible to forge signatures and this guarantees confidence in the correctness of the answers. But there is a hitch again, the digital signatures are built on obsolete algorithms. And quantum computers can break them again. So even the basic structure of the Internet will require changes. Of the basic services, this applies to both DNS (more precisely DNSSEC) and Network Time Protocol (NTP). Without it, it is not possible to verify whether the certificate or proof of accuracy is still valid at this moment. In addition to these protocols, however, it is necessary to change the routing protocols, which provide information on how to get through the maze of the Internet to a particular system. Without appropriate verification, it is not possible to trust the exchange of information about a route change. This includes network surveillance services … and could be continued.
Is that all? No, we are still in the beginning. In addition to the above communication channels, there are the current wireless networks. What could possibly be wrong with an ordinary WiFi network? I would allow myself a small fix, not only on WiFi, but also Bluetooth uses weak cryptography. And not only those. This also applies to today's wireless networks for the industry of things, automated systems including building environment management and a large number of other systems. Here it is not possible to just change supported cryptography, it will probably be necessary to replace components. Again, this is a huge cost, and there are still no solutions available for some technologies. But it also applies to wireless networks for mobile communications. For the moment, let's forget about 2G/3G/4G networks. If we are talking about 5G networks and considered 6G networks, only a few algorithms can be considered as resilient, most of the others will have to be changed. For such large networks, it is again an economic nightmare. For all of the above systems, who will bear the burden of proof of the correct implementation? Who will be responsible for the correct implementation? How will it be shown that it is not just pages in the documentation, when the real implementation lags behind the above descriptions? The proof requires verification of the correct implementation and at the same time measurement of how the transfer is made. In the case of these communication channels, this is an extremely difficult measurement.
Unfortunately, if it is possible to change these technologies in a way that guarantees resilience, it is still not won. It is necessary to change the support at the level of the applications that use these networks and services. As an example, you can think of a digital signature (expression of will, proof of key ownership or other uses). If the currently accepted signature is using algorithms such as RSA or ECDSA, it will not be trusted in the future. Therefore, the application must be able to use up-to-date cryptographic algorithms. Examples are programs designed for managing the economy of organizations, systems for contract management, document exchange within the supply-customer chain, data protection… This also applies to relatively common issues such as protection by encrypting data storage in disk arrays, computers or mobile phones, or encrypting backups. Today, users do not only use data storage tools, but also have to communicate with each other. Therefore, such a generational change will also affect various messengers and collaborative tools, providing virtual meetings and document sharing. It will also affect the change in the protection of e-mail communication. It still does not stop there. In order to save time and costs, it is necessary to use knowledge in this area, which should be summarised in BIA (Business Impact Analysis) and risk analysis. The extent of the impact at the application level differs for each organization, of course.
Another significant impact will be on the financial sector. In banking, these are complete changes to payment systems, which include, for example, changing terminals and smart cards, provided by card associations. It will be necessary to change the connections between ATMs and banks. Some will be new technologies of card companies providing secure payments by card, other changes await us for payments over the internet and others, which again brings huge costs. Ideally, there will be a change that the user will not recognize. But this may not be true, after all, we will soon (hopefully) recognize it.
The last small step concerns the mechanisms that we overlook on a daily basis. This is the cornerstone of most security solutions. This cornerstone is known as authentication mechanisms. Most of them are two to three decades old and are not able to cope with this change. Further use of these mechanisms thus leads to an extreme increase in the risk to the operation of the company. The reason is simple. The attacker will be able to intercept, break and then falsify any communication as if it were not even protected, thanks to weak authentication mechanisms. If he acts under the name of an employee, the chances of detecting this attack until it is too late are extremely low. Currently, such attacks are being carried out and are known as Business Account Compromise (BAC). Only the technologies of quantum computers are not used, but the techniques of social engineering.
Areas of interest. Please note, this is only an indicative overview, it is not intended to provide an exhaustive analysis.

  • Internet infrastructure: NTP, DNSSEC, RPKI, routing protocols and verification of their information ...
  • Trust services: PKI (certificates and their infrastructure)
  • Communications networks: WiFi, Bluetooth, 4G/5G/6G, other radio communications including industrial communications, Internet of Things, automation of operations (e.g. buildings) and other systems
  • VPN networks: IPSec, MACSEC, OpenVPN, SSL/TLS VPN, SSTP, WireGuard …
  • Payment and banking systems
  • Electronic mail, various communicators (messengers), collaborative tool
  • Backup systems
  • Key economy management and management systems: tokens, chip cards and other HSMs, KMS
  • Storage encryption systems: Computers, mobile phones, external drives, disk arrays
  • Authentication mechanisms
  • Supply chain data sharing applications, electronic payment applications, sensitive document management applications and others, not specified here

How to plan and when to make the transition?

If an organisation decides to make changes to cryptography, it must be approached with discretion. Rapid implementation is not a happy solution. Most libraries started development in 2015-2020, so test versions are now available. During 2025, the first versions, which are intended for production deployment, should start to appear. Thus, migration should not start until the end of 2025 until the beginning of 2026. On the other hand, there is a limit set by the upcoming standards, when migration of algorithms should be completed by certain deadlines. For example, for key negotiation by 2030. Digital signature algorithms could theoretically be available until 2035, but this situation may change. One alternative is to force migration for critical infrastructure by 2027, end support for obsolete algorithms by 2030, and similar deadlines. Therefore, it is necessary to start preparing and analyzing today and monitor not only the development of cryptography, but also standards.

Comparison of mechanisms, test method and test environment

A small flaw in the whole migration process is the lack of information. For a large part of the industry, not only is there no information about algorithms, but there is also no information about impacts on systems load. Current testing systems suffer from certain ailments, there are errors that could cause these systems to weaken or break. This is due to the rapid development, which sometimes comes up against the limits of human capabilities. This, of course, has an effect in trying to create a counterweight. An example is the effort to create library functions capable of proving the accuracy of implementation (the FORMOSA project). Anyway, any deployment of these technologies depends on knowledge of the architecture of the protocols, what the impact of the new algorithms will be on the operation, the latency of transmissions and other “details”. Therefore, it is necessary to perform stress tests and verify the system's ability to cope with this load. The good news is the possibility to make at least a basic comparison of the performance of the individual algorithms. For the above reasons, this comparison must be considered indicative, as it varies according to the platform used, the systems deployed and the libraries.
This comparison contains both obsolete mechanisms from today's point of view and new ones. These are two sets, where the first covers KEM (Key Exchange Mechanism) algorithms. These are algorithms providing key agreement (calculation of a shared key without having to transfer it) and key exchange (one side determines the key and provides it to the other side). The second set contains DSA (Digital Signature Algorithm) algorithms, i.e. digital signature algorithms. The actual testing was done on a configuration containing:

  • 13th Gen Intel® Core™ i7-1365U × 12, 64GB RAM
  • Ubuntu 24.04.1 LTS
  • OpenSSL 3.0.13
  • OpenSSL OQS Provider 0.8.1-dev
  • liboqs 0.12.0 compiled with LMS and XMSS support
The published tests apply to one kernel out of twelve, yet tests were also done on two, four, eight and a full number of cores. Further, control tests were done on the ARM (Raspberry PI) platform for one, two and four cores. Since libraries have different capabilities, I am preparing further tests for different types of libraries so that the limitations of libraries and algorithms can be determined more accurately, including the ability to work on multi-processor systems. Data collection tied to a limited number of cores was done as follows:

# taskset -ac 11 /git/liboqs/build/tests/speed_kem | tee /git/oqs_onecore_speed_kem.txt
# taskset -ac 11 /git/liboqs/build/tests/speed_sig | tee /git/oqs_onecore_speed_sig.txt
# taskset -ac 11 /git/liboqs/build/tests/speed_sig_stfl | tee /git/oqs_onecore_speed_sig_stfl.txt
# taskset -ac 11 /git/liboqs/build/tests/speed_common | tee /git/oqs_onecore_speed_common.txt
# taskset -ac 11 /bin/openssl speed | tee /git/oqs_onecore_openssl_speed.txt

The taskset command sets a limit for the use of processor kernels, i.e. the results were different for each group. The resulting data was processed and expressed as the number of operations of the given type per second. Thus, how many operations such as encryption, decryption, key generation, digital signature, signature verification or key agreement are capable of being executed by the algorithm per second.

Algorithm Property Evaluation

This section describes the measured data. The graphs process similar type of algorithms and approximately identical security equivalents, the table below the graph shows specific values in the number of executed operations per second and the corresponding security equivalents for each algorithm.
The first set of graphs describes classical algorithms such as Diffie Hellman, Diffie Hellman over elliptic curves, RSA and Diffie Hellman over community elliptic curves. Here you can see the effectiveness of elliptic curves, which can only be competed to some extent by decryption in an RSA algorithm. On the other hand, I made my work with RSA much easier. Thanks to the similarity of the algorithm for encryption and signing (the difference for a signature is only in the encryption of the hash function output over a specific text), it is possible to use the same results with a slight degree of inaccuracy.



AlgorithmSecurity EquivalentKeygenEncapsulateDecapsulateAgreement
FFDH 20481123464,8
FFDH 30721281349,6
FFDH 4096168570,3
FFDH 6144192241,9
FFDH 8192256137
NIST P-256 (ECDH)12816512,4
NIST P-384 (ECDH)1921323,8
NIST P-521 (ECDH)2603225,8
RSA 30721280,664494,427219,4485,580
RSA 40961680,306247,414748,8243,319
RSA 76801920,02323,43903,223,261
RSA 153602560,002551152,84,978
X25519 (ECDH)12826754
X448 (ECDH)2244893,1


The next graph shows the result of PQC algorithms. For comparison, they are accompanied by results for agreement on X25519 and X448 keys, which do not belong to these algorithms. Depending on the result, at the same or higher security level, grid algorithms achieve roughly the same performance and outperform the RSA algorithm. The measured values can be found in the table.



AlgorithmSecurity EquivalentKeygenEncapsulateDecapsulateAgreement
Classic-McEliece-34886412815,52755855,3335866,6675309,041
Classic-McEliece-4608961287,47518575,66730922650,768
Classic-McEliece-66881281923,9956303,3334287,3332551,727
Classic-McEliece-69601191923,28293646488,3333832,669
Classic-McEliece-81921282562,12414687,66742443292,603
Kyber102425634783,66710207229347063,376
Kyber51212868846,333351963002116201,590
Kyber76819246515,6671867725690,66710814,736
ML-KEM-1024256226381338326857,6678932,162
ML-KEM-5121287164723381,33347206,33315636,542
ML-KEM-76819236573,6671512334720,33310534,520
sntrup761128720,76028950,66738577,66716538,971


Digital signature algorithms are presented in three separate graphs. The corresponding tables are assigned to them. The first are classical digital signature algorithms based on historical DSA, RSA and ECDSA/EdDSA.



AlgorithmSecurity EquivalentKeygenSignVerify
DSA 51264019654,832211,8
DSA 10249609889,114836,8
DSA 204811203983,14271
RSA 20481121,9611548,750371,7
RSA 30721280,664494,427219,4
RSA 40961680,306247,414748,8
RSA 76801920,02323,43903,2
RSA 153602560,00351152,8
NIST P-256 (ECDSA)128045333,914065,6
NIST P-384 (ECDSA)19201271,51476,8
NIST P-521 (ECDSA)26005085,61951
Ed25519 (EdDSA)128025986,99880,7
Ed448 (EdDSA)22805568,44792,6


The next graph shows the result of PQC algorithms. For comparison, they are accompanied by digital signature results based on Ed25519 and Ed448, which again do not belong to these algorithms. According to the result, they have slightly less power than elliptic curves, yet still outperform the RSA algorithm.



AlgorithmSecurity EquivalentKeygenSignVerify
ML-DSA-4412881627189,66716879
ML-DSA-6519249764962,3338400,333
ML-DSA-872564349,3334227,3334050,333
Falcon-51212877,97438886567,667
Falcon-102425632,8251956,66710865,333
SPHINCS+-SHA2-128f-simple128687,77180,506812,667
SPHINCS+-SHA2-192f-simple192716,42851,316323,333
SPHINCS+-SHA2-256f-simple256497,16815,240338,887
SPHINCS+-SHAKE-128f-simple128906,39614,393506,498
SPHINCS+-SHAKE-192f-simple192341,65815,177421
SPHINCS+-SHAKE-256s-simple2566,6581,411309,667
Ed25519 (EdDSA)12825986,99880,7
Ed448 (EdDSA)2285568,44792,6


The last group are signatures based on XMSS and LMS technologies. These are mechanisms where signature creation takes significantly longer, but are effective in authentication.
• For LMS (Leighton-Micali Signature), the W value (Winternitz parameter) changes the overall efficiency of the algorithm. A higher value means shorter signatures, allows faster authentication, but also seems to increase the signing time. At the same time, shorter signatures could be vulnerable to some, now mainly theoretical, attacks.
• In the case of XMS, two basic tree types can be encountered. XMSS (single-level structure - eXtended Merkle Signature Scheme) and XMSSMT (multi-level structure - XMSS Merkle Tree). • The H value changes the tree height in the case of LMS and XMSS/XMSSMT, has a minor effect on performance. A higher depth here allows for more signatures to be created.



AlgorithmSecurity EquivalentKeygenSignVerify
LMS_SHA256_H10_W41287,3162,25712378,667
LMS_SHA256_H10_W4_H5_W81283,8904,747608,667
LMS_SHA256_H10_W81280,6270,829734,755
LMS_SHA256_H15_W11280,2680,29716621,333
LMS_SHA256_H15_W21280,2710,23725121,000
LMS_SHA256_H15_W41280,1550,12611125,333
LMS_SHA256_H5_W1128118,01985400428679
LMS_SHA256_H5_W2128153,61595981015824,667
LMS_SHA256_H5_W4128124,2099321575073
LMS_SHA256_H5_W812820,930424308652,449
LMS_SHA256_H5_W8_H5_W812810,6429,769426,240
XMSSMT-SHA2_20/2_2561280,283268,8211081,612
XMSSMT-SHA2_20/4_2561284,640543,333459,667
XMSSMT-SHA2_40/2_2561280,001128,700918,333
XMSSMT-SHA2_40/4_2561280,263269,730363,212
XMSSMT-SHA2_40/8_2561284,152527,315134,577
XMSSMT-SHA2_60/12_2561284,219327,006119,333
XMSSMT-SHA2_60/3_2561280,0004172,6091006,333
XMSSMT-SHA2_60/6_2561280,160192,295170,610
XMSSMT-SHAKE_20/2_2561280,14864,655343,199
XMSSMT-SHAKE_20/4_2561281,127133,822117,862
XMSSMT-SHAKE_40/2_2561280,000164,772345,424
XMSSMT-SHAKE_40/4_2561280,06947,17679,307
XMSSMT-SHAKE_40/8_2561281,68947,95264,645
XMSSMT-SHAKE_60/12_2561280,70598,96755,648
XMSSMT-SHAKE_60/3_2561280,000138,308148,950
XMSSMT-SHAKE_60/6_2561280,05123,58891,303
XMSS-SHA2_10_192962,051263,7361909,333
XMSS-SHA2_10_2561281,152309,3811077,308
XMSS-SHA2_10_5122560,17640,026252,916
XMSS-SHA2_16_192960,023326,2251390,667
XMSS-SHA2_16_2561280,018345,5391364,212
XMSS-SHA2_16_5122560,00329,627318,894
XMSS-SHA2_20_192960,001346,6531397,867
XMSS-SHA2_20_2561280,001218,3751168,333
XMSS-SHA2_20_5122560,000233,799279,813
XMSS-SHAKE_10_2561280,31963,312860,333
XMSS-SHAKE_10_5122560,08112,280216,189
XMSS-SHAKE_16_2561280,00447,461802,333
XMSS-SHAKE_16_5122560,00127,27970,455
XMSS-SHAKE_20_2561280,000392,023496,503
XMSS-SHAKE_20_5122560,000125,55969,597
XMSS-SHAKE256_10_192960,55267,063541,667
XMSS-SHAKE256_10_2561280,34047,540833,000
XMSS-SHAKE256_16_192960,00669,172606,465
XMSS-SHAKE256_16_2561280,00446,048506,000
XMSS-SHAKE256_20_192960,000493,719387,075
XMSS-SHAKE256_20_2561280,000365,210672,661


Precautionary principle

Despite all the advantages of new mechanisms, it is necessary not to rush the transition. It is necessary to implement it in a relatively short time, but on the other hand, it is advisable to consider the risks. Every new system, including cryptography, needs time to find possible errors. During previous development, errors were found in protocols or in the architecture, even after a decade. At present, we have significantly better tools for analyzing and detecting such errors, just as developments (that is, our knowledge) in this area have shifted. Nevertheless, I would recommend caution in the case of the deployment of quantum computer-resistant technologies. We have a short, almost gallows term here, when the implementation must be mastered. The operational view requires a bridging period, when new and old algorithms will be available in parallel. For the above reasons, therefore, it should be deployed first on systems that do not process sensitive data. Only after the functionality and correctness of deployment is verified is a gradual implementation possible for more sensitive environments. At the same time, it is necessary to prepare contingency procedures for vulnerability detection, where a conservative approach can be defined on the basis of such a procedure for a limited period of time. By this we mean older technologies.

Conclusion

The transition to the post-quantum era will certainly not be a walk in the park. Still, a significant advantage is the increase in speed for some of the quantum computer-resistant algorithms, which means lower computational performance requirements. Organisations with knowledge of their environment, the impacts of implementation and possible downtime will have an advantage. Equally, organisations that plan the transition in cooperation with their business partners will have an advantage. This change is necessary, and without information on the scope and impacts it can end up in a very unfortunate way. Hopefully, temporary unavailability will be the worst thing that can happen to such organisations.

Reference:

  1. liboqs
    Source: https://openquantumsafe.org/
  2. OQS Provider
    Source: https://openquantumsafe.org/
  3. GitHub liboqs
    Source: https://github.com/
  4. GitHub OQSProvider
    Source: https://github.com/

Autor článku:

Jan Dušátko
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.

Consent to the collection and processing of personal data

According to Regulation (EU) No 2016/679 of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data and repealing Directive 95/46/EC (General Data Protection Regulation, hereinafter referred to as "the Regulation"), the processor xxx (hereinafter referred to as "the Controller") processes personal data. Individual personal data that are part of the processing during specific activities at this web presentation and in the course of trade are also broken down.
Although the collection of data is ubiquitous, the operation of this website is based on the right to privacy of each user. For this reason, the collection of information about users takes place to the extent absolutely necessary and only if the user decides to contact the operator. We consider any further collection and processing of data unethical.

Information about the records of access to the web presentation

This website does not collect any cookies. The site does not use any analytical scripts of third parties (social networks, cloud providers). For these reasons, an option is also offered for displaying the map in the form of a link, where the primary source is OpenStreet and alternatives then the frequently used Maps of Seznam, a.s., or Google Maps of Google LLC Inc. The use of any of these sources is entirely at the discretion of the users of this site. The administrator is not responsible for the collection of data carried out by these companies, does not provide them with data about users and does not cooperate on the collection of data.
Logging of access takes place only at the system level, the reason being the identification of any technical or security problems. Other reasons are overview access statistics. No specific data is collected or monitored in this area and all access records are deleted after three months.

Information about contacting the operator of the site

The form for contacting the operator of the site (administrator) contains the following personal data: name, surname, e-mail. These data are intended only for this communication, corresponding to the address of the user and are kept for the time necessary to fulfil the purpose, up to a maximum of one year, unless the user determines otherwise.

Information about the order form

In case of an interest in the order form, the form contains more data, i.e. name, surname, e-mail and contact details for the organisation. These data are intended only for this communication, corresponding to the address of the user and are kept for one year, unless the user determines otherwise. In the event that a business relationship is concluded on the basis of this order, only the information required by Czech law on the basis of business relations (company name and address, bank account number, type of course and its price) will continue to be kept by the administrator.

Information about the course completion document

Within the course, a course completion document is issued by the processor. This document contains the following data: student's name and surname, the name and date of the course completion and the employer's name. The information is subsequently used for the creation of a linear hash tree (non-modifiable record). This database contains only information about the provided names and company names, which may or may not correspond to reality and is maintained by the processor for possible re-issuance or verification of the document's issuance.

Rights of the personal data subject

The customer or visitor of this website has the possibility to request information about the processing of personal data, the right to request access to personal data, or the right to request the correction or deletion of any data held about him. In the case of deletion, this requirement cannot be fulfilled only if it is not data strictly necessary in the course of business. The customer or visitor of this website also has the right to obtain explanations regarding the processing of his personal data if he finds out or believes that the processing is carried out in violation of the protection of his private and personal life or in violation of applicable legislation, and the right to request removal of the resulting situation and to ensure the correction.
Furthermore, the customer/visitor of this website may request restriction of processing or object to the processing of personal data and has the right to withdraw his/her consent to the processing of personal data at any time in writing, without prejudice to the lawfulness of their processing prior to such withdrawal. For this purpose, the contact e-mail address support@cryptosession.cz is used.
The customer/visitor has the right to file a complaint against the processing of personal data with the supervisory authority, which is the Office for Personal Data Protection.