Blog
Quantum Computer-Resistant Cryptography - Digital Signatures
In the previous article were the algorithms for key agreement discussed. In this, I want to focus on digital signatures, which are currently not only one form of integrity protection, but are also used for authentication or as proof of will. Working with these signatures is easy to understand in classical algorithms such as DSA, ECDSA/EdDSA and RSA. In short, it is the creation of a hash of text, which is then encrypted by the algorithm. The recipient then decrypts this value and checks whether the hash matches. The procedure is valid for RSA, it is different for DSA/ECDSA/EdDSA. For simplicity, this idea can be taken into account. But what is the situation with signatures using quantum-resistant algorithms. The following article is not a mathematical description, but an attempt to explain the principles, so again it resorts to simplifications and straightforks.
Merkle trees
These are hash trees, not ornamental trees. This tree grows from the leaves, where every two leaves are hashed to form a twig. Then two twigs are hashed to form a branch ... and this goes on to a defined depth. The last record is the root. It seems strange, but Merkle trees have been used for years in some cryptocurrencies, for example. They are used in other places, like in computer memories as a control mechanism that is faster than the ECC (in this case it is the Error Correction Code, not the Eliptic Curve Cryptography). And you could go on.
WOTS signatures
One of the basic building blocks of quantum-resistant quantum algorithms is currently the so-called WOTS signature
(Winternitz One-Time Signature). It is built above hash functions, its principle consists in re-hashing some data. In
the model example, a one-time signature will be used and the whole situation is greatly simplified.
At the beginning, I generate a private key, which consists of several blocks of data. Each block of data has an output width
corresponding to the hash function width. In this case, the example will be SHA256 with a block width of 32B. Since even the
signed text will have this hash function output width, we must have an appropriate number, i.e. 32 blocks. Based on these
settings, each block will be repeatedly hashed. After 256 hashes of each block, a public key is created. But how to create and
verify the signature?
When we calculate the hash of text, each byte determines how many times we will hash the private key (one of 32 blocks each).
Once the entire signature is created (32x32B=1024B), we can attach it to the document. Based on the current possibilities,
we can't figure out what data the hash was calculated from. On the other hand, we can take the hash of the text and figure
out how many more times we need to hash the block by the difference in the value of the given byte. And if the result matches
the public key, the signature is fine. The problem is only the size. Both the private key and the public key are 1KB in size
under these conditions. For each B message, we used one 32B string. On the other hand, we can use any other number of bits
as a counter just as well. According to current knowledge, this mechanism is safe.
For schemes based on hash trees, either the classic WOTS signature or WOTS+ is used. Both of these signatures are defined
in RFC, but the important thing is the difference. WOTS is slower and has bigger keys, and with that, of course, the signatures.
WOTS+ has smaller keys, it is faster, and it also protects against some types of attack on WOTS. The protection in this case
is provided by masking the outputs between the rounds.
Status and stateless digital signatures
Digital signatures using quantum-resistant algorithms can be built over different principles and combinations of them.
Today, grid algorithms and algorithms using hash functions are widely accepted. Unlike classical asymmetric cryptography,
there has been a significant change in this area. And this has to be taken into account in the design of the system. This is
a problem of status and stateless signatures. What does this actually mean?
Status signatures are a group of algorithms that need to define how many times they can be used during the design. This makes
them different from the resources currently used and creates a problem with maintenance. The owner of the key material has
to keep track of the number of uses. With each signature, the key changes, more precisely, another part of it is used. And if
the key is used multiple times, the attacker has the ability to obtain the private key and completely compromise the entire
signature history.
For the LMS, XMSS and XMSSMT status algorithms, the number of signatures can be selected. The listed schemes are based on
the hash tree and these trees have a unique structure. The structure is extremely important for the number of signatures,
more specifically the keys. The tree has a certain depth (h) and in the case of multi-layered trees (XMSMT) it has a certain
number of layers (d). Because it is a binary tree, the number of signatures corresponds to the number 2h. If it
is a multi-layered structure, the number of signatures corresponds to 2h*d. the status trees are intended only
for the following algorithms, based on the hash tree:
- LMS - Leighton-Micali Signature (Merkle tree)
- XMSS - eXtended Merkle Signature Scheme
- XMSSMT - XMSS Multi-Tree - hierarchy of Merkle trees
Other proposed mechanisms do not have status properties, i.e. they are technologies similar to what we use. They are significantly closer in user comfort to current technologies and their principles. This, of course, simplifies certificate management and does not force administrators or users to learn new procedures that could be confusing for them. The stateless algorithms can thus be ranked:
- ML-DSA (originally Krystal Dilithium, currently Module Lattice DSA according to FIPS 204)
- SLH-DSA (originally SPHINCS+, currently Stateless Hash-Based DSA according to FIPS 205)
- FN-DSA (originally Falcon, currently Fast Fourier Transform-based NTRU DSA according to FIPS 206)
ML-DSA
This algorithm uses a similar principle to classical asymmetric signature algorithms. More precisely, a similar principle
to the so-called Schnorr signature was directly inspired by it. In some cases, the signature principle is referred to as
Fiat-Shamir, which is even closer to the algorithm. The Schnorr signature also uses its principle, but in a different way.
But how does the signing work? A private key and a random prompt create a work output, which is then used to create two parts
of the signature. One of the values contains the signed data and the work value, the other contains a random input (also used
to create the work value) added to the hash and secret key multiples. And vice versa, if the recipient wants to verify the data,
it uses the public key to perform a series of mathematical operations over the said parts of the signature. This yields
a secret value, which it connects to the signed data (without the signature) and tries to hash it. If the information in the signature
and the result of the operation is the same, the signature is also fine. But such a description probably to few what he says.
If I am to avoid any other description, the algorithm can be described even more easily, but with considerably less accuracy.
We can imagine a hall that is completely paved with the same tiles of a rectangular shape. This is a two-dimensional space,
in a real situation there will be significantly more of these dimensions. If I try to make a signature, I will choose one
of the tiles that I will mark with my signature. At the same time, I will calculate two values that are part of the signature,
but are modified using a private key. If the recipient wants to verify the signature, he must perform operations over
it using a public key. This will determine the coordinates of the signature. This is a very loose analogy, but the aim
of this article is not a detailed description of the algorithm.
The above algorithm is extremely fast, but its sensitivity to the chosen inputs is discussed. As with classical algorithms,
protection must be ensured from using two identical randomness values for different texts. In this case, it was possible
to easily solve the quadratic equation to arrive at a private key. Unfortunately, it turned out that using a good randomness
generator may not be sufficient. Under certain specific conditions, some bits of the key can "leak" into the signature.
This problem has been proven for the ECDSA algorithm, and this knowledge can be used for attack. Likewise, knowledge
of randomness inputs can be used to attack ML-DSA.
SLH-DSA
In this case, it is a combination of FORS (Forest of Random Subsets) signature, which is then signed using WOTS+ signature
using XMSS tree. The complete algorithm is more difficult to visualize, but the following can be used to approximate it.
The FORS signature will hash the message. It will divide this message into separate parts, which are taken as an address
within the generated hash trees. One part determines this part of the hash output determines which tree, the other a specific
hash value within the tree. Thus, it is possible to imagine this signature as creating a list of hash addresses, generated
from some input. But how is this actually done, and how is this process linked to WOTS+ signatures and Merkle trees?
The private key for SLH-DSA consists of the values SecretKey.seed, SecretKey.pseudorandomfunction, PublicKey.seed and
PublicKey.root. The public key contains only PublicKey.seed and PublicKey.root. PublicKey.root is the root for the Merkle
hash trees. It generates separate trees for the FORS signature. In order to differentiate these values, SecretKey.seed
is used for random changes from the public key, i.e. the attacker is unable to get information about the initial values.
The message hash thus addresses the generated address records within the FORS tree, including the path to its root. Subsequently,
the resulting data of the public part of the FORS signature is passed to the WOTS+ scheme. This scheme uses a completely
different Merkle tree for creating the final signature and ensuring trust. In fact, it is a signature over small seals.
FORS acts as the document stamping clerk and WOTS+ as the notary who signs all documents with a stamp.
As a result, it is a robust, albeit relatively complex system. Its parameters limit the number of signatures (224,
232, ... 264), yet it is not state-of-the-art. One-time keys are generated on the basis of information
about the signed data. This could be compared to a situation where the number of signatures counter would be generated
on the basis of the hash of the signed data. A similar example exists between ECDSA and EdDSA. While ECDSA generates nonce
randomly, EdDSA generates it on the basis of the hash of the data and the private key. This reduces the probability of
a collision to a slim value.
FN-DSA
This algorithm is built on grids, which is the shape formed by folding vectors. Since the vectors are not identical, it is possible to imagine the grids as rectangular tiles that pave the hall. This hall has two layers of tile, the basic one being made up of private keys. Public keys make an additional layer that is derived from private keys. It can be imagined as semi-transparent tiles. This makes it impossible to see the "joints," meaning the grids of private keys. In case of an attempt to create a signature, the hash of the data is calculated again. This is changed to a vector in the grid by the GPV (Gentry-Peikert-Vaikuntanathan) procedure. At this point, a mathematical apparatus such as FFT (Fourier Transformation) comes in, looking for a specific location point for this vector so that there is as little distance between it and the center of the tile as possible. It can be imagined as placing the target under semi-transparent tiles on a grid of private keys (hash). Thanks to the public key, it is possible to identify the nearest center of the tile and verify that the hash and signature information is correct. The digital signature is made up of the signature vector, the hash function identifier and other information. This is usually the optional context within which the signature is performed.
LMS
As mentioned at the beginning, Leighton-Micali Signature is among the status signatures. For this reason, it is necessary
to work hard to keep the order of signatures, because in no case must two different information be signed with the same
key. Apart from the need to keep the status, the scheme is significantly slower. In addition, it is designed for a lower
level of security than, for example, XMSS (another scheme), and thanks to the intensive use of key material, it will soon
run out. As an additional curiosity, this scheme uses WOTS+ signatures, explained at the beginning of the article. But why
should it make sense to use LMS despite all these limitations?
Because there is a defined number of possible signatures, including their serial numbers, continuity is ensured. This can
be interesting for example for a firmware digital signature or an update of some software packages. At the same time, it
carries a certain risk. Already in the design, a certain maintenance cycle and lifetime must be taken into account. Therefore,
for any changes outside of regular updates, a reserve must be available, a public key correction is no longer possible.
How does this mechanism actually work? At the beginning, a Merkl tree is created, which has a predefined number of hashes
at its endpoints. To create a hash above the selected dates, we can prepare a WOTS+ signature, which is then represented
in the form of a path to the given endpoint. Thus, the signature contains paths that allow to recreate the original hash
of the message, followed by the serial number of the signature. Based on the information available, it is possible to calculate
the root of the tree, which allows comparing the information with the public key.
If we want to visualize this, we can give an example of a large office. Each official will have a set of stamps that can
only be used once. The office is the root of the tree, the official is one of the nodes, and there are specific stamps
at the end. If a document needs to be stamped, the official responsible for the document will randomly choose one of the
stamps, add a document to the document to get the stamp (office, floor, door, official, shelf with stamps, box with specific
stamps), stamp the document and put the stamp back in the box. Since he can only use it once, the important thing is not
the number of the stamp, but the way to get the stamp. In this case, it is possible to verify the consistency of the number
on the document and the stamp. Thus, verify its validity.
XMSS/XMSSMT
XMSS/XMSSMT are schemes somewhat similar to the previous LMS. Unlike the previous scheme, XMSS/XMSSMT support a significantly
larger number of signatures with a single key due to the definable tree depth. Even these signatures have a certain maximum
number of key uses, but this is of the order of magnitude completely different. Further, they are intended for more
security-intensive environments. In the case of XMSSMT (Multi Tree), the total capacity is then increased by using more
Merkle hash trees. Even these signature schemes are slow. but thanks to proven security, this is a good deal.
When comparing the security parameters between LMS, XMSS and XMSSMT, there is a difference in the number of signatures based
on the tree depth and in the case of Mutli Tree, in the number of trees. LMS has for 128b security equivalent of the tree
depth h=8, which for 2h, i.e. 28 corresponds to a maximum of 256 signatures. For 192b security equivalent
is 216, i.e. 65536 signatures. For XMSS, the values are 224=16777216, 232=4294967296 and
finally 264 with a huge number of 1,844×1019 signatures. In the case of a multi-tree structure, the number
can then increase significantly.
Because LMS and XMSS are very similar, there is no need to describe the properties. The principle of signature creation and
analogies are the same. If we were to talk about implementation and precise description, there are a few differences. However,
these are usually below the distinctiveness of most people. They should be addressed by people who are dedicated to this topic
and have sufficiently deep mathematical knowledge.
Overview
A table containing data related to individual signatures and comparing the volume of data used. By default, sizes in bits are used. If a unit is specified, the size of the output depends on the parameters of the algorithm configuration.
| Algorithm | Standard | Secret key (bit) | Public key (bit) | Data used (bit) | Signature size (bit) |
| ML-DSA-44 | FIPS 204 | 20480 | 10496 | 128 (SHAKE128) | 19360 |
| ML-DSA-65 | FIPS 204 | 22256 | 15616 | 128 (SHAKE128) | 26472 |
| ML-DSA-87 | FIPS 204 | 39168 | 20736 | 256 (SHAKE256) | 37016 |
| FN-DSA-512 | FIPS 206 | 10248 | 7176 | 256 (SHAKE256) | 5328 |
| FN-DSA-768 | Not in standard | 14856 | 10760 | 256 (SHAKE256) | 8000 |
| FN-DSA-1024 | FIPS 206 | 18440 | 14344 | 256 (SHAKE256) | 10240 |
| SLH-DSA-128 | FIPS205 | 512 | 256 | 256 (SHA256) | ~ 8KB |
| SLH-DSA-192 | FIPS205 | 512 | 256 | 512 (SHA512) | ~ 12KB |
| SLH-DSA-256 | FIPS205 | 512 | 256 | 512 (SHA512) | ~ 16KB |
| LMS-128 | RFC 8554 | Depends on tree depth | 256 | 256 (SHA256) | ~ 1KB - 2KB |
| XMSS-128 | RFC 8391 | Depends on tree depth | 256 | 256 (SHA256) | ~ 2,5KB - 3KB |
| XMSS-192 | Not in standard | Depends on tree depth | 256 | 256 (SHA256) | ~ 3KB - 4KB |
| XMSS-256 | Not in standard | Depends on tree depth | 256 | 256 (SHA256) | ~ 3KB - 6KB |
| XMSSMT-128 | Not in standard | Depends on tree depth | 256 | 256 (SHA256) | ~ 2,5KB - 4KB |
| XMSSMT-192 | RFC 8391 | Depends on tree depth | 256 | 256 (SHA256) | ~ 3KB - 4KB |
| XMSSMT-256 | RFC 8391 | Depends on tree depth | 256 | 256 (SHA256) | ~4KB - 6KB |
Conclusion
In some cases, the transition to quantum-computer-resistant cryptography entails a significant change in approach. Current technologies are not perfect and face new attacks threatening their security. This is of course part of normal development. For these reasons, administrators and system owners will have to think about whether and how to change digital signing requirements, but also system architecture or estimation of computational requirements. Algorithms in particular LMS/XMSS/XMSSMT are machine-time eaters when calculating digital signatures, on the other hand they allow extremely quick signature verification.
Reference:
- 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 - Fast Fourier Transform-based NTRU Digital Signature Standard
Source: https://www.nist.gov/ - RFC 8554 - Leighton-Micali Hash-Based Signatures
Source: https://www.rfc-editor.org/ - RFC 8391 - XMSS: eXtended Merkle Signature Scheme / Multi Tree Scheme
Source: https://www.rfc-editor.org/ - IACR - An attack on ML-DSA using an implicit hint
Source: https://eprint.iacr.org/
Autor článku:
Podobné články
Your learning platform for cryptography
and security.
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.