Man
Professional
- Messages
- 3,077
- Reaction score
- 614
- Points
- 113
Despite the fact that research in the field of post-quantum cryptography is gaining momentum every day, the practical application of the obtained results is very lazily implemented in real products. This is largely due to well-founded concerns about the timeliness and practicality of this. Many experts consider this process premature. However, scientists are persistently developing various post-quantum applications. As a famous paranoid and reinsurer, I am rather on the side of the latter, since I clearly imagine the day when a technological breakthrough will occur and at the same moment most cryptographic schemes will order a long life, covered with a respectable copper basin of implementations of Shor's algorithm. Mass hysteria cannot be avoided, for example, as now with generative AI. Unlike the same problems with suddenly too smart AI, the practical application of which is not yet fully understood and is brewing in the cauldron of public opinion with obvious attempts to limit uncontrolled development, with the leap in quantum computing such a number is unlikely to work. Everything that can be hacked will be hacked, and the world will plunge into chaos...
Perhaps, everything is not so bad, but better safe than sorry, so the sooner post-quantum systems are implemented, the more likely the chance to avoid unpleasant consequences of this technological breakthrough. Today, there are several approaches to implementing such protection. Although, perhaps, the most realistic approach in the near future will be based on hash-based cryptography. An example of such a system is the public key scheme in the form of a Merkle hash tree, developed back in 1979 and based on the ideas of Lamport and Diffie.
The issue of security and reliability of modern electronic devices is very broad and touches upon many different theoretical and practical aspects. However, there is one subtle and common point for most devices that I would like to focus on in this article - the process of their booting. Different devices can be "loaded" with well-protected software components, algorithms and protocols, but no system will be safe if it is opened before the process of booting this very protected software. Therefore, secure boot is one of the cornerstones of electronic systems, the elimination of which can lead to fundamental security problems. Therefore, the implementation of post-quantum protection at this level is of paramount importance.
The boot process plays an important role in ensuring security and reliability. The primary executable part of the software is stored in persistent memory and the execution of the boot code is the first step that ensures that only reliable and genuine software is executed from the start. The importance of this role, combined with the practical difficulty of updating, requires extremely reliable developer decisions and carefully tested software. This applies especially to the cryptographic primitives used, but is far from limited to them. Most modern implementations work on common asymmetric algorithms such as RSA or ECC. And as I already mentioned, these algorithms are at risk due to the development of quantum computers.
To prepare for this threat, the National Institute of Standards and Technology (NIST) launched a process to standardize quantum-resistant cryptographic algorithms in 2016. At one point, NIST selected the stateless hash -based signature (HBS) scheme SPHINCS+ for standardization. It is the only algorithm chosen that does not rely on the security of lattice cryptography. Stateless schemes can be used in the same way as conventional digital signature algorithms based on RSA and ECC. In contrast, stateful schemes require the signer to keep track of the keys already in use, since only a limited number of signatures can be generated per key pair. Any failure to do so seriously reduces security. The advantage of stateful schemes over stateless schemes is a smaller signature size and execution speed.
For two stateful HBS schemes, Leighton - Micali Hash-Based Signatures (LMS) and eXtended Merkle Signature Scheme (XMSS), IETF RFCs are available (1, 2). Based on these documents, NIST published a recommendation for the use of stateful HBS back in 2020. In 2022, ANSSI (Agence nationale de la sécurité des systèmes d'information) published recommendations for the deployment of HBS, and BSI (British Standards Institution) published recommendations for stateful HBS. The main feature of such schemes is that their security depends only on the properties of the underlying hash functions.
Since hash functions are well understood, this makes HBS schemes a very conservative choice, especially compared to other post-quantum cryptography algorithms. Due to this and their maturity, hybridization will not be required, making HBS ideal for secure boot. Boot processes are very time-sensitive, and therefore signature verification is part of these processes. The verification time of a hash-based signature is largely determined by the underlying hash function. As a result, HBS schemes can be implemented in end devices with minimal additional costs, which in itself plays into the hands of proponents of this approach.
Hardware hash accelerators can be quickly replaced at relatively little cost. In one study I reviewed, the developers integrated a hardware accelerator into OpenTitan. OpenTitan is an open-source security controller based on a 32-bit RISC-V processor. For comparison, OpenTitan's secure boot process was examined with existing hardware-accelerated signature checks based on RSA and ECC.
The developers do not recommend using any one of the HBS implementations for all devices, since such an approach is not practical in real applications. This is due to the fact that different devices have different limitations (for example, in terms of computing power).
In recent years, stateful schemes have been evaluated for use in secure boot or for general use with efficient implementations. These implementations range from software evaluations, including comparisons of different schemes, to systems-on-chips with varying levels of hardware acceleration, to full hardware designs. However, a universal and flexible HBS solution for implementing secure boot is still missing.
So, let's look at several variants of the schemes.
Hash-based signatures are digital signature schemes that use hash functions as the underlying cryptographic primitive. How and which of these cryptographic primitives are combined allows for the construction of either a so-called stateful or stateless HBS scheme. Using a stateful HBS algorithm is different for the signer compared to conventional asymmetric cryptographic algorithms. Essentially, the number of signatures that can be securely generated is limited by the total number of key pairs available. Each key pair can only be used once, and any reuse will result in a security breach. Thus, the signer must keep track of key pairs that have already been used, effectively storing state and updating it after each signature generation.
In contrast, the use of stateless HBS corresponds to classical asymmetric cryptographic algorithms. In addition to stateful and stateless schemes, HBS schemes can be divided into two variants: “simple” and “complex”, for which different security arguments can be made regarding the hash function used. “Simple” instances have a less conservative security argument but better performance. In contrast, “complex” instances meet more conservative security requirements but are less resource-efficient.
The starting point of the hash chain is a random value corresponding to a single OTS secret key (red). The intermediate value of the hash chain is the blue OTS signature. The endpoint of the hash chain is the OTS public key (white). The function K is applied to these endpoints to generate the compressed OTS public key (yellow). For the compression function K, LMS and SPHINCS+ use a custom hash function, while XMSS uses a so-called L -tree. The signature and verification operations are similar in nature. To sign or verify a message, its digest is split into log2(w) bit pieces, and each piece is interpreted as a value a. For signature “red” → “blue” and verification “blue” → “yellow”, each hash chain is advanced.
For signature, it advances by a, and for verification, by w-1-a. In the case of verification, the signature is valid if the candidate public key is identical to the public key. The length of the function chain and the bit size of the fragment are determined by the Winternitz parameter w and log2(w), respectively. In the example in the figure, the message is divided into fragments of 2 bits, which corresponds to the Winternitz parameter w of 4. The WOTS method was proposed by Robert Winternitz of Stanford. It uses relatively small key and signature sizes and is considered quantum-resistant. In general, it generates random private keys of size 32×256 bits. We then receive them several times, which is determined by the parameter w.
Overview of a random subset forest diagram with secret key (red), public key (dark yellow), signature (blue), and authentication path nodes (purple)
The leaves are thus the hashes of the secret keys. To create the signature, the message digest is split into k a- bit fragments, as shown in the figure. Each fragment is interpreted as an integer, which is used as an index to select a secret key as a signature node. This is done for all k trees and fragments. The selected nodes are concatenated together with the corresponding nodes of the authentication path. The same approach is used to verify the signature as in the verification of the WOTS signature. For comparison, the same message is signed in the OTS and FORS examples shown in Figures 1 and 2, respectively.
The MSS signature consists of the OTS signature described above and is a kind of authentication path in the context of HBS. Starting from the bottom of the figure, the OTS public key is computed from the signature. The nodes of the authentication path are then used to generate a candidate public key for the corresponding signature. The signature is valid if the candidate public key is identical to the known public key. With MSS, OTS can be extended to multiple signature MTS. This HBS design is applicable to real use cases, but is still impractical for a large number of key pairs, i.e., signatures, required.
The height of the tree h is limited by the time it takes to generate and sign the keys. To overcome this limitation, a generalized Merkle signature scheme (GMSS) is introduced. Its basic idea is to construct a so-called certification tree with multiple MSSs. Instead of having one MSS with a large Merkle tree, it is divided into d signatures, each of which is a smaller Merkle tree.
The practical applicability of HBS schemes involves flexible joint development of hardware and software to improve the performance of signature verification. The design methodology requires dividing algorithmic operations into three classes: hash chain formation, authentication paths, and unclassified operations.
The unclassified part of the operations takes less than 10% on average, so this part is less important for hardware acceleration. At the same time, the calculation of the hash chain is responsible for more than 80% of the total latency during verification. Therefore, this is the most interesting part for acceleration. The authentication path takes up to 15% of the performance of SPHINCS+, which makes it a possible second target for modification.
Typically, hashing dominates the execution time of HBS algorithms. Thus, any speedup in hash computation has a significant impact on overall performance. SHA-2/3 hardware cores are found in many microcontrollers, as they are often used. Using such an accelerator shifts the bottleneck from computation to communication with the accelerator. On the OpenTitan target platform, SHA-256 compression takes 65 cycles, while writing data and reading the digest increases the latency to about 1400 cycles. For digesting large amounts of data, this does not matter, since the transmission is interleaved with computation, and the compression function is executed multiple times. However, for one step in the hash chain, from 55 (LMS) to at most 96 bytes ( XMSS ) are digested simultaneously. Therefore, a general-purpose hash accelerator is not ideal for use in hash chains.
The speedup that can be achieved with general-purpose hash cores is limited by the high communication overhead. Because of the tree and chain structures in HBS schemes, data structures are accessed incrementally. Dedicated hardware components can manage this data flow and therefore reduce the interaction with the main processor. Therefore, the use of hardware accelerators that support computing the hash chain, the root of the tree, or both is quite feasible.
As described above, OTS verification consists mainly of advancing along hash chains. According to preliminary estimates, the hash chain module allows higher Winternitz parameters to be used without significant degradation of overall performance, while as the chain length increases, the number of required I/O operations decreases, and the execution time decreases accordingly, even if more hash operations are required. Purely software implementations, on the contrary, imply a linear increase in execution time as the number of required F operations increases.
Using a combination of hardware and software, it is possible to reduce the signature size without affecting performance. For example, you can choose the Winternitz parameter w = 256 instead of w = 16 to reduce the OTS signature size by half without significantly reducing performance. The figure below shows the kernel diagram.
The original OpenTitan SHA-256 accelerator consists of a SHA-256 backend that can be accessed either transparently or via an HMAC upper layer to compute SHA-256 or MAC, respectively. By reusing the SHA-256 logic, additional manufacturing costs can be minimized. During synthesis, one of six HBS modules can be included in the design: LMS, XMSS, SPX+-s, SPX+-r, (SPX+-s + LMS), (SPX+-r + XMSS). In theory, these modules can be adapted to any hash cores with minor modifications.
In this design, modifications to the original hash accelerator include a chain register that is connected to the SHA-256 initial state register, additional control logic to switch between operating modes, and a feedback path to the HBS module. The HBS cores implement the appropriate behavior using simple state machines. This design can be directly integrated into any chip that supports the TileLink Uncached Lightweight (TL-UL) interface.
Today, research into the implementation of post-quantum algorithms is actively ongoing, but it can already be said that such a transition using HBS schemes is quite feasible. Flexible hardware and software configuration to support both stateful and stateless schemes allows reducing hardware overhead. At the same time, the discussion about the choice between stateless and stateful HBS is indifferent to the underlying hardware and specific implementations depend only on the features of specific devices. For example, purely software implementations are mostly unsuitable for embedded devices, while hardware implementation is always more expensive in terms of overhead and costs, and the applicability of purely hardware implementations in IoT devices is unlikely to be fully feasible. Considering that IoT devices in this context will be the very "sick man of Europe". Therefore, a combined approach is preferable at this stage.
Source
Perhaps, everything is not so bad, but better safe than sorry, so the sooner post-quantum systems are implemented, the more likely the chance to avoid unpleasant consequences of this technological breakthrough. Today, there are several approaches to implementing such protection. Although, perhaps, the most realistic approach in the near future will be based on hash-based cryptography. An example of such a system is the public key scheme in the form of a Merkle hash tree, developed back in 1979 and based on the ideas of Lamport and Diffie.
The issue of security and reliability of modern electronic devices is very broad and touches upon many different theoretical and practical aspects. However, there is one subtle and common point for most devices that I would like to focus on in this article - the process of their booting. Different devices can be "loaded" with well-protected software components, algorithms and protocols, but no system will be safe if it is opened before the process of booting this very protected software. Therefore, secure boot is one of the cornerstones of electronic systems, the elimination of which can lead to fundamental security problems. Therefore, the implementation of post-quantum protection at this level is of paramount importance.
The boot process plays an important role in ensuring security and reliability. The primary executable part of the software is stored in persistent memory and the execution of the boot code is the first step that ensures that only reliable and genuine software is executed from the start. The importance of this role, combined with the practical difficulty of updating, requires extremely reliable developer decisions and carefully tested software. This applies especially to the cryptographic primitives used, but is far from limited to them. Most modern implementations work on common asymmetric algorithms such as RSA or ECC. And as I already mentioned, these algorithms are at risk due to the development of quantum computers.
To prepare for this threat, the National Institute of Standards and Technology (NIST) launched a process to standardize quantum-resistant cryptographic algorithms in 2016. At one point, NIST selected the stateless hash -based signature (HBS) scheme SPHINCS+ for standardization. It is the only algorithm chosen that does not rely on the security of lattice cryptography. Stateless schemes can be used in the same way as conventional digital signature algorithms based on RSA and ECC. In contrast, stateful schemes require the signer to keep track of the keys already in use, since only a limited number of signatures can be generated per key pair. Any failure to do so seriously reduces security. The advantage of stateful schemes over stateless schemes is a smaller signature size and execution speed.
For two stateful HBS schemes, Leighton - Micali Hash-Based Signatures (LMS) and eXtended Merkle Signature Scheme (XMSS), IETF RFCs are available (1, 2). Based on these documents, NIST published a recommendation for the use of stateful HBS back in 2020. In 2022, ANSSI (Agence nationale de la sécurité des systèmes d'information) published recommendations for the deployment of HBS, and BSI (British Standards Institution) published recommendations for stateful HBS. The main feature of such schemes is that their security depends only on the properties of the underlying hash functions.
Since hash functions are well understood, this makes HBS schemes a very conservative choice, especially compared to other post-quantum cryptography algorithms. Due to this and their maturity, hybridization will not be required, making HBS ideal for secure boot. Boot processes are very time-sensitive, and therefore signature verification is part of these processes. The verification time of a hash-based signature is largely determined by the underlying hash function. As a result, HBS schemes can be implemented in end devices with minimal additional costs, which in itself plays into the hands of proponents of this approach.
Hardware hash accelerators can be quickly replaced at relatively little cost. In one study I reviewed, the developers integrated a hardware accelerator into OpenTitan. OpenTitan is an open-source security controller based on a 32-bit RISC-V processor. For comparison, OpenTitan's secure boot process was examined with existing hardware-accelerated signature checks based on RSA and ECC.
The developers do not recommend using any one of the HBS implementations for all devices, since such an approach is not practical in real applications. This is due to the fact that different devices have different limitations (for example, in terms of computing power).
In recent years, stateful schemes have been evaluated for use in secure boot or for general use with efficient implementations. These implementations range from software evaluations, including comparisons of different schemes, to systems-on-chips with varying levels of hardware acceleration, to full hardware designs. However, a universal and flexible HBS solution for implementing secure boot is still missing.
So, let's look at several variants of the schemes.
Hash-based signatures are digital signature schemes that use hash functions as the underlying cryptographic primitive. How and which of these cryptographic primitives are combined allows for the construction of either a so-called stateful or stateless HBS scheme. Using a stateful HBS algorithm is different for the signer compared to conventional asymmetric cryptographic algorithms. Essentially, the number of signatures that can be securely generated is limited by the total number of key pairs available. Each key pair can only be used once, and any reuse will result in a security breach. Thus, the signer must keep track of key pairs that have already been used, effectively storing state and updating it after each signature generation.
In contrast, the use of stateless HBS corresponds to classical asymmetric cryptographic algorithms. In addition to stateful and stateless schemes, HBS schemes can be divided into two variants: “simple” and “complex”, for which different security arguments can be made regarding the hash function used. “Simple” instances have a less conservative security argument but better performance. In contrast, “complex” instances meet more conservative security requirements but are less resource-efficient.
One-time signatures
The basis of modern HBS algorithms are one-time signature (OTS) schemes. LMS, XMSS and SPHINCS+ use the Winternitz OTS (WOTS) variant. The basic idea is to have a certain number of function chains, i.e. to repeatedly apply a function F to the previous output. For convenience, we assume that the function F consists of only one call to a cryptographic hash function with the previous output as the only input. Thus, in the following we simply use the term hash chain for this particular construction. The working principle of such OTS schemes is depicted in the figure.The starting point of the hash chain is a random value corresponding to a single OTS secret key (red). The intermediate value of the hash chain is the blue OTS signature. The endpoint of the hash chain is the OTS public key (white). The function K is applied to these endpoints to generate the compressed OTS public key (yellow). For the compression function K, LMS and SPHINCS+ use a custom hash function, while XMSS uses a so-called L -tree. The signature and verification operations are similar in nature. To sign or verify a message, its digest is split into log2(w) bit pieces, and each piece is interpreted as a value a. For signature “red” → “blue” and verification “blue” → “yellow”, each hash chain is advanced.
For signature, it advances by a, and for verification, by w-1-a. In the case of verification, the signature is valid if the candidate public key is identical to the public key. The length of the function chain and the bit size of the fragment are determined by the Winternitz parameter w and log2(w), respectively. In the example in the figure, the message is divided into fragments of 2 bits, which corresponds to the Winternitz parameter w of 4. The WOTS method was proposed by Robert Winternitz of Stanford. It uses relatively small key and signature sizes and is considered quantum-resistant. In general, it generates random private keys of size 32×256 bits. We then receive them several times, which is determined by the parameter w.
Reusable signatures
In contrast to the OTS scheme, the few -time signature (FTS) scheme allows a key pair to be reused multiple times. The FTS scheme is used only in the stateless HBS scheme SPHINCS+. As a result, the overall height of the SPHINCS+ tree can be significantly reduced, making it relatively easy to implement in practice. In the context of SPHINCS+, a forest of random subsets (FORS) scheme is used to sign message digests. FORS consists of k Merkle trees, each of height a. To generate a FORS public key, all k root nodes of the Merkle tree are compressed. One tree authenticates t = 2a FORS secret keys.
Overview of a random subset forest diagram with secret key (red), public key (dark yellow), signature (blue), and authentication path nodes (purple)
The leaves are thus the hashes of the secret keys. To create the signature, the message digest is split into k a- bit fragments, as shown in the figure. Each fragment is interpreted as an integer, which is used as an index to select a secret key as a signature node. This is done for all k trees and fragments. The selected nodes are concatenated together with the corresponding nodes of the authentication path. The same approach is used to verify the signature as in the verification of the WOTS signature. For comparison, the same message is signed in the OTS and FORS examples shown in Figures 1 and 2, respectively.
Merkle signature scheme
In OTS or FTS schemes, one key pair can be used for signature one or more times, respectively. To overcome this limitation, the Merkle signature scheme (MSS) is used, shown in the figure below. It uses a Merkle tree to authenticate multiple OTS public keys. Each leaf node in the Merkle tree corresponds to one hashed OTS public key. The root node of the tree corresponds to the MSS public key, which is used to authenticate OTS public keys. A Merkle tree of height h authenticates 2h OTS key pairs.
The MSS signature consists of the OTS signature described above and is a kind of authentication path in the context of HBS. Starting from the bottom of the figure, the OTS public key is computed from the signature. The nodes of the authentication path are then used to generate a candidate public key for the corresponding signature. The signature is valid if the candidate public key is identical to the known public key. With MSS, OTS can be extended to multiple signature MTS. This HBS design is applicable to real use cases, but is still impractical for a large number of key pairs, i.e., signatures, required.
The height of the tree h is limited by the time it takes to generate and sign the keys. To overcome this limitation, a generalized Merkle signature scheme (GMSS) is introduced. Its basic idea is to construct a so-called certification tree with multiple MSSs. Instead of having one MSS with a large Merkle tree, it is divided into d signatures, each of which is a smaller Merkle tree.
| Algorithm | Parameter | Signature size | Public key size | NIST Security Level | |
| LMS | h=15 | w=4 | 4.7 KiB | 32 B | 5 |
| h=15 | w=16 | 2.7 KiB | 32 B | 5 | |
| h=15 | w=256 | 1.6 KiB | 32 B | 5 | |
| XMSS | h=16 | w=16 | 2.6 KiB | 32 B | 5 |
| SPHINCS+ | 256s | 29 KiB | 64 B | 5 | |
| RSA | 3072 | 384 B | 384 B | ? | |
| ECC | P-256 | 64 B | 64 B | ? |
SPHINCS+
Unlike XMSS and LMS, SPHINCS+ parameters are described by a specific set of combinations. The available list of parameters can be divided into two variants: "small" and "fast", which are denoted by the letters s and f, respectively. The "small" variant has a slow key generation and signing speed, but provides a smaller signature size and faster verification, which is more relevant for secure boot. The corresponding signature and public key size for the selected parameter set is also indicated in the table. The "easy" and "hard" schemes that can be used in SPHINCS+ affect only the security proof and execution time, and do not affect the signature or public key size. Hereinafter, they are denoted as SPX+-s and SPX+-r.The practical applicability of HBS schemes involves flexible joint development of hardware and software to improve the performance of signature verification. The design methodology requires dividing algorithmic operations into three classes: hash chain formation, authentication paths, and unclassified operations.
The unclassified part of the operations takes less than 10% on average, so this part is less important for hardware acceleration. At the same time, the calculation of the hash chain is responsible for more than 80% of the total latency during verification. Therefore, this is the most interesting part for acceleration. The authentication path takes up to 15% of the performance of SPHINCS+, which makes it a possible second target for modification.
Typically, hashing dominates the execution time of HBS algorithms. Thus, any speedup in hash computation has a significant impact on overall performance. SHA-2/3 hardware cores are found in many microcontrollers, as they are often used. Using such an accelerator shifts the bottleneck from computation to communication with the accelerator. On the OpenTitan target platform, SHA-256 compression takes 65 cycles, while writing data and reading the digest increases the latency to about 1400 cycles. For digesting large amounts of data, this does not matter, since the transmission is interleaved with computation, and the compression function is executed multiple times. However, for one step in the hash chain, from 55 (LMS) to at most 96 bytes ( XMSS ) are digested simultaneously. Therefore, a general-purpose hash accelerator is not ideal for use in hash chains.
The speedup that can be achieved with general-purpose hash cores is limited by the high communication overhead. Because of the tree and chain structures in HBS schemes, data structures are accessed incrementally. Dedicated hardware components can manage this data flow and therefore reduce the interaction with the main processor. Therefore, the use of hardware accelerators that support computing the hash chain, the root of the tree, or both is quite feasible.
As described above, OTS verification consists mainly of advancing along hash chains. According to preliminary estimates, the hash chain module allows higher Winternitz parameters to be used without significant degradation of overall performance, while as the chain length increases, the number of required I/O operations decreases, and the execution time decreases accordingly, even if more hash operations are required. Purely software implementations, on the contrary, imply a linear increase in execution time as the number of required F operations increases.
Using a combination of hardware and software, it is possible to reduce the signature size without affecting performance. For example, you can choose the Winternitz parameter w = 256 instead of w = 16 to reduce the OTS signature size by half without significantly reducing performance. The figure below shows the kernel diagram.
The original OpenTitan SHA-256 accelerator consists of a SHA-256 backend that can be accessed either transparently or via an HMAC upper layer to compute SHA-256 or MAC, respectively. By reusing the SHA-256 logic, additional manufacturing costs can be minimized. During synthesis, one of six HBS modules can be included in the design: LMS, XMSS, SPX+-s, SPX+-r, (SPX+-s + LMS), (SPX+-r + XMSS). In theory, these modules can be adapted to any hash cores with minor modifications.
In this design, modifications to the original hash accelerator include a chain register that is connected to the SHA-256 initial state register, additional control logic to switch between operating modes, and a feedback path to the HBS module. The HBS cores implement the appropriate behavior using simple state machines. This design can be directly integrated into any chip that supports the TileLink Uncached Lightweight (TL-UL) interface.
Today, research into the implementation of post-quantum algorithms is actively ongoing, but it can already be said that such a transition using HBS schemes is quite feasible. Flexible hardware and software configuration to support both stateful and stateless schemes allows reducing hardware overhead. At the same time, the discussion about the choice between stateless and stateful HBS is indifferent to the underlying hardware and specific implementations depend only on the features of specific devices. For example, purely software implementations are mostly unsuitable for embedded devices, while hardware implementation is always more expensive in terms of overhead and costs, and the applicability of purely hardware implementations in IoT devices is unlikely to be fully feasible. Considering that IoT devices in this context will be the very "sick man of Europe". Therefore, a combined approach is preferable at this stage.
Source
