Results 1  10
of
37
Efficient generation of shared RSA keys
 Advances in Cryptology  CRYPTO 97
, 1997
"... We describe efficient techniques for a number of parties to jointly generate an RSA key. At the end of the protocol an RSA modulus N = pq is publicly known. None of the parties know the factorization of N. In addition a public encryption exponent is publicly known and each party holds a share of the ..."
Abstract

Cited by 151 (5 self)
 Add to MetaCart
We describe efficient techniques for a number of parties to jointly generate an RSA key. At the end of the protocol an RSA modulus N = pq is publicly known. None of the parties know the factorization of N. In addition a public encryption exponent is publicly known and each party holds a share of the private exponent that enables threshold decryption. Our protocols are efficient in computation and communication. All results are presented in the honest but curious settings (passive adversary).
A Simplified Approach to Threshold and Proactive RSA
 In Proceedings of CRYPTO
"... We present a solution to both the robust threshold RSA and proactive RSA problems. Our solutions are conceptually simple, and allow for an easy design of the system. The signing key, in our solution, is shared at all times in additive form, which allows for simple signing and for a particularly ..."
Abstract

Cited by 94 (2 self)
 Add to MetaCart
We present a solution to both the robust threshold RSA and proactive RSA problems. Our solutions are conceptually simple, and allow for an easy design of the system. The signing key, in our solution, is shared at all times in additive form, which allows for simple signing and for a particularly efficient and straightforward refreshing process for proactivization. The key size is (up to a very small constant) the size of the RSA modulus, and the protocol runs in constant time, even when faults occur, unlike previous protocols where either the size of the key has a linear blowup (at best) in the number of players or the run time of the protocol is linear in the number of faults. The protocol is optimal in its resilience as it can tolerate a minority of faulty players.
Building Intrusion Tolerant Applications
 In Proceedings of the 8th USENIX Security Symposium
, 1999
"... The ITTC project (Intrusion Tolerance via Threshold Cryptography) provides tools and an infrastructure for building intrusion tolerant applications. Rather than prevent intrusions or detect them after the fact, the ITTC system ensures that the compromise of a few system components does not compromis ..."
Abstract

Cited by 68 (0 self)
 Add to MetaCart
(Show Context)
The ITTC project (Intrusion Tolerance via Threshold Cryptography) provides tools and an infrastructure for building intrusion tolerant applications. Rather than prevent intrusions or detect them after the fact, the ITTC system ensures that the compromise of a few system components does not compromise sensitive security information. To do so we protect cryptographic keys by distributing them across a few servers. The keys are never reconstructed at a single location. Our designs are intended to simplify the integration of ITTC into existing applications. We give examples of embedding ITTC into the Apache web server and into a Certication Authority (CA). Performance measurements on both the modied web server and the modied CA show that the architecture works and performs well. 1 Introduction To combat intrusions into a networked system one often installs intrusion detection software to monitor system behavior. Whenever an \irregular" behavior is observed the software noties an admi...
Experimenting with Shared Generation of RSA keys
, 1999
"... We describe an implementation of a distributed algorithm to generate a shared RSA key. At the end of the computation, an RSA modulus N = pq is publicly known. All servers involved in the computation are convinced that N is a product of two large primes, however none of them know the factorization of ..."
Abstract

Cited by 40 (0 self)
 Add to MetaCart
(Show Context)
We describe an implementation of a distributed algorithm to generate a shared RSA key. At the end of the computation, an RSA modulus N = pq is publicly known. All servers involved in the computation are convinced that N is a product of two large primes, however none of them know the factorization of N . In addition, a public encryption exponentispublicly known and each server holds a share of the private exponent. Such a sharing of an RSA key has many applications and can be used to secure sensitive private keys. Previously, the only known method to generate a shared RSA key was through a trusted dealer. Our implementation demonstrates the e#ectiveness of shared RSA key generation, eliminating the need for a trusted dealer. 1 Introduction To protect an RSA private key, one may break it into a number of pieces #shares# and store each piece at a separate location. Sensitive private keys, such as Certi#cation Authority #CA# keys, can be protected in this way. Fortunately, for the RSA cr...
Chosen ciphertext secure public key threshold encryption without random oracles
 in Proceedings of RSACT 2006
, 2006
"... Abstract. We present a noninteractive chosen ciphertext secure threshold encryption system. The proof of security is set in the standard model and does not use random oracles. Our construction uses the recent identity based encryption system of Boneh and Boyen and the chosen ciphertext secure const ..."
Abstract

Cited by 35 (6 self)
 Add to MetaCart
(Show Context)
Abstract. We present a noninteractive chosen ciphertext secure threshold encryption system. The proof of security is set in the standard model and does not use random oracles. Our construction uses the recent identity based encryption system of Boneh and Boyen and the chosen ciphertext secure construction of Canetti, Halevi, and Katz.
Exposing an RSA Private Key Given a Small Fraction of its Bits
, 1998
"... We show that for low public exponent RSA, given a quarter of the bits of the private key an adversary can recover the entire private key. Similar results (though not as strong) are obtained for larger values of e. For instance, when e is a prime in the range [N^(1/4), N^(1/2)], half the bits of the ..."
Abstract

Cited by 30 (0 self)
 Add to MetaCart
We show that for low public exponent RSA, given a quarter of the bits of the private key an adversary can recover the entire private key. Similar results (though not as strong) are obtained for larger values of e. For instance, when e is a prime in the range [N^(1/4), N^(1/2)], half the bits of the private key suffice to reconstruct the entire private key. Our results point out the danger of partial key exposure in the rsa public key system.
Twoparty generation of DSA signatures
 In Advances in Cryptology — CRYPTO 2001
, 2001
"... Abstract. We describe a means of sharing the DSA signature function, so that two parties can e±ciently generate a DSA signature with respect to a given public key but neither can alone. We focus on a certain instantiation that allows a proof of security for concurrent execution in the random oracle ..."
Abstract

Cited by 27 (7 self)
 Add to MetaCart
Abstract. We describe a means of sharing the DSA signature function, so that two parties can e±ciently generate a DSA signature with respect to a given public key but neither can alone. We focus on a certain instantiation that allows a proof of security for concurrent execution in the random oracle model, and that is very practical. We also brie°y outline a variation that requires more rounds of communication, but that allows a proof of security for sequential execution without random oracles. 1
WitnessBased Cryptographic Program Checking and Robust Function Sharing
, 1996
"... We suggest a new methodology for "result checking" that enables us to extend the notion of Blum's program result checking to the online checking of cryptographic functions. In our model, the checker not only needs to be assured of the correctness of the result but the owner of the pr ..."
Abstract

Cited by 26 (4 self)
 Add to MetaCart
We suggest a new methodology for "result checking" that enables us to extend the notion of Blum's program result checking to the online checking of cryptographic functions. In our model, the checker not only needs to be assured of the correctness of the result but the owner of the program needs to be sure not to give away anything but the requested result on the (authorized) input. The existing approaches for program result checking of numerical problems often ask the program a number of extra queries (different from the actual input). In the case of cryptographic functions, this may be in contradiction with the security requirement of the program owner. Additional queries, in fact, may be used to gain unauthorized advantage (for example, imagine the implications of the online checking of a decryption device that requires the decryption of extra ciphertexts). In [Blum88], the notion of a simple checker was introduced where, for the purpose of efficiency, extra queries are not allowed...
Cryptovirology: ExtortionBased Security Threats and Countermeasures
 In Proceedings of the IEEE Symposium on Security and Privacy
, 1996
"... Traditionally, cryptography and its applications are defensive in nature, and provide privacy, authentication, and security to users. In this paper we present the idea of Cryptovirology which employs a twist on cryptography, showing that it can also be used offensively. By being offensive we mean th ..."
Abstract

Cited by 25 (1 self)
 Add to MetaCart
(Show Context)
Traditionally, cryptography and its applications are defensive in nature, and provide privacy, authentication, and security to users. In this paper we present the idea of Cryptovirology which employs a twist on cryptography, showing that it can also be used offensively. By being offensive we mean that it can be used to mount extortion based attacks that cause loss of access to information, loss of confidentiality, and information leakage, tasks which cryptography typically prevents. In this paper we analyze potential threats and attacks that rogue use of cryptography can cause when combined with rogue software (viruses, Trojan horses), and demonstrate them experimentally by presenting an implementation of a cryptovirus that we have tested (we took careful precautions in the process to insure that the virus remained contained). Publickey cryptography is essential to the attacks that we demonstrate (which we call "cryptovirological attacks"). We also suggest countermeasures and mechanis...