# Tag Info

10

If the RSA keys were generated randomly, then it is inconceivable that two different devices would happen to pick the same key. Taking 2048 bit RSA keys as an example, there are approximately $2^{1014}$ 1024 bit primes; if we consider them pairwise (and realise that about half the pairs yield a 2047 bit number), that means there are about $2^{2026}$ RSA ...

6

As fgrieu notes, the problem as specified is unsolvable: if the server alone should not be able to decrypt the files, then there must be something (in this case, the password) possessed by the user but not the server which is needed to decrypt them. If the user loses this extra information, there's no way the server can provide them access to the files ...

6

No. The challenge for RSA-155 (which is 512 bits) was broken in 1999. This took 6 months on pretty advanced hardware to break at the time, which works out to 8000 MIPS years. It should be much less today. FYI, RSA 768 took just under 3 years.

6

On point 1: the question worded, reduced to common practice, is equivalent to: assume that we generate $k=2$ RSA public keys with public modulii $N$ of $n=2048$ bits, with prime factors $p$, $q$ random in range $[2^{(n-1)/2}\dots2^{n/2}]$, and public exponent $e=2^{16}+1$; what are the odds that any two of the $k$ public keys $(N,e)$ are the same? Applying ...

6

A lot of sleepless nights for the CA, their customers, web browser and OS developers, and Slashdot users, that's what. I don't know if a CA has ever had their private keys compromised, but there have been incidents where their systems were broken into and fraudulent certificates were issued. (There's a difference between a private key actually being taken, ...

5

Public key crypto vs. identity-based crypto made short: In traditional public key cryptography, a user $A$ generates a private/public key pair $(sk_A,pk_A)$ and since this key pair has absolutely no indication to which indentity (user $A$) it belongs, it is necessary to certify the public key, i.e., bind the public key $pk_A$ to the user $A$'s identity. ...

4

I don't have any experience with this myself, but Tom Ritter talked about this on twitter: Matthew Green: Out of curiosity: do you happen to know offhand how much it costs to factor a 512-bit RSA key on EC2? Tom Ritter: My personal costs are \$120-\$150 with my setup. You can probably do it cheaper, heard reports of \$75. He also published a ... 4 There was a post on security.stackexchange last week about this. SSL/TLS with Certificate Authorities for all intents and purposes is now completely insecure from governments and any organisation who has a CA pre-trusted inside the standard web browsers. DNSSEC will also fall under the same scenario because at the top level you have a particular government ... 4 It's impossible to say what the device really does; there are so many possible ways. If you don't find any technical specification describing it, I would be wary of the actual security of the device. If the device is FIPS 140 approved at any level, you can find back the FIPS certificate and the relevant security policy on this NIST web page. 4 No, this is not correct. Your fallacy here is to assume that a public-key infrastructure implies RSA. RSA is just a way of implementing an PKI. There are other cryptographic schemes out there that do not reduce to the problem of factoring large numbers. 4 Under a chosen-plaintext attack, the adversary has the power to encrypt polynomially-many chosen plaintexts. In the symmetric world, since only the valid parties hold the encryption key, only the valid parties can "grant" the adversary access to an encryption oracle. So, it isn't assumed that an eavesdropper necessarily has access to an encryption oracle. ... 4 That's correct. If this happens, then your PKI is doomed and you have to set it up again and roll out all the certificates again. Actually, then not all the certificates are "compromised" in the sense of key compromise, but you cannot longer trust them, since if someone is in possession of the root private key, this person can issue arbitratrily dated ... 3 There is "PGP network of trust" (also implemented by other OpenPGP-compatible systems like GnuPG) which does exactly that. You start off with nobody to trust except yourself. You decide to trust some friends of yours and hand your public key to them to have it signed. This signed public key will be automatically trusted by anyone else who trust your ... 3 I prefer a ~128 bit security level. With ECC this means a curve with ~256 bits, with DH or RSA this corresponds to around 3000 bits. If you can accept a lower security level, the advantage of ECC over DH/RSA gets smaller. My favourite is Curve25519, which has easily available high performance implementations. An alternative is P256 which is a NIST standard, ... 3 The answer to the question: Is there any way to store private keys that are encrypted with a users clear text password and still have a way when resetting a password to preserve access to the users data is actually yes. Simply store two copies of each private key - one encrypted with the user's password and one encrypted with the administrator's public ... 3 Short answer: the problem you're trying to solve can't be fully satisfactorily solved. With the assumption that an adversary control your system to the point of being able to read the RAM containing secret keys, you won't be able to define a secure system. The closest thing to a real practical solution is to bring in a trusted execution environment. HSMs ... 2 It is not correct. Actually, your usage of RSA is entirely wrong. In a public key scheme, there are 2 keys, one for encryption and one for decryption. If you use the private key to encrypt.... the public key would be used to decrypt. That means everyone can decrypt, as the public key is public. If you use a public key scheme and the private key to create ... 2 Store the key encrypted. Send the encrypted key to the user and have them decrypt it and sign the message. Whatever your objections are to this scheme, they are most likely either misguided or can be addressed by the implementation of the scheme. 2 Considering special purpose hardware, according to [40] sieving for a 1024-bit RSA modulus can be done in a year for about US \$10,000,000, plus a one-time development cost of about US \$20,000,000, and with a comparable time and cost for the matrix. -- Bos et al. RSA.816 offers very short-term protection against small organizations Should not be ... 2 I do not know what the practice is, much less what your particular device do, but I can tell what could be done. The token could contain a secure Micro-Controller Unit, complete with CPU(s), RAM, Non-Volatile Memory (EEPROM or Flash), crypto accelerators for symmetric and asymmetric crypto, and a communication interface (USB, or perhaps ISO-IEC 7816-3 with ... 2 I'll answer the second question even if nightcracker correctly stated that PKI isn't bound to integer factorization per se. To look for symmetric encryption protocols for authentication you do not have to look further to the market for public transport cards and access cards. Many of these systems rely on a chip card that just rely on random and symmetric ... 2 Another approach is done by the Perspective Project. With it you setup your server and it will monitor the certificates of the sites. You can then subscribe to any number of these monitoring servers and verify them against each other. Since you decide which ones you want to trust, instead of 1 certificate being certifiable by just 1 person, it should be ... 2 That depends on the concrete CRL. As long as you have access to your private key, you can sign the revocation request. This prevents anyone without access to the private key from issuing a faked revocation request. With access to the private key, a faked revocation request can be sent. But in this case the damage is already done, and a revocation is ... 2 When a (EC)DHE (non-anon) cipher suite is used, the server's public key is used to verify the signature of the ServerDHPublic. Diffie-Hellman is an anonymous key-exchange protocol. A signature is used to make sure that the client is talking with who he thinks to talk and no MITM attack has took place. 2 In short: The parent CA would sign the public key of an n-time signature scheme, as opposed to the public key of a signature scheme which is valid for an unbounded number of signatures (the current design). n-time signature schemes are usually just constructed by generating n instances of a one-time signature scheme and then accumulating their public keys ... 1 This is a very interesting question, in the sense that every smart card provider claims the inviolability of its own process. Nowadays, Smart cards can generate their cryptographic keys on the card itself using appropriate hardware. Entropy is generally generated by an embedded random generator. The hardware of the generator is generally certified by ... 1 You can search for root certificates of a given CA. E.g.: http://www.symantec.com/page.jsp?id=roots, but this page is served over plain HTTP so maybe you shouldn't trust it! or https://www.mozilla.org/projects/security/certs/included/. From there when you want to check a certificate you can check whether it belongs to/was signed by a root CA you trust. ... 1 No, since compromising the communication$\:\implies\:$compromising the PKI setup$\:\implies$falsely claiming that a party generated a particular public key$\:\implies\:\$ "if Alice … immediately." . Yes, we might assume that. Note that, if the channel can carry voice, then faking a comparison can require voice impersonation. This is the idea behind ...

1

Let me propose you this: Try to write down your protocol without any security proofs. Since you think that there are no attacks, give it a try here: Proverif (http://prosecco.gforge.inria.fr/personal/bblanche/proverif/) or Scyther (http://people.inf.ethz.ch/cremersc/scyther/). They are tools for formal verification of protocols. Not only will they tell you ...

1

If you cannot provide even a basic proof of security, or a reduction of the protocol security to the underlying algorithms in use, you should assume the protocol is insecure. Even with a security proof, a logical analysis of attacks against the protocol should be performed, as a proof may be limited to security against a limited amount of attacks, and in ...

Only top voted, non community-wiki answers of a minimum length are eligible