# Tag Info

12

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 ...

10

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 ... 10 First an important point of terminology: the real question should be phrased "Why not just sign the whole message with the private key of Bob, send it to Alice, and verify it with Bob's public key?". Signature and encryption are very different things. We use "encryption" only when the goal is confidentiality; and encryption is performed with the public key ... 9 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. 9 No, there is no known efficient method to find an RSA private key from public key, ciphertext and plaintext, including when no padding is used and$e=3$. The best known method is factoring the public modulus, which then trivially allows to find a working private key. Factoring is considered brute force, or tantamount to that. The best known factoring method ... 8 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 ... 8 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, ... 7 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. ... 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 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 ... 6 Among the reason why root public keys are often expressed as a self-signed certificate are: It cryptographically protects against a deliberate alteration of an attribute of the public key (e.g. extension of validity period, or of what the key can be used for). It strongly protects against accidental alteration of the public key value. It is a reasonably ... 6 None. You don't trust the Root CA certificate because it was signed by anything - you trust the Root CA because you (or someone on your behalf) placed it in your trust anchor store. A Root CA certificate has a signature simply because it is mandatory within the X509 specification - it serves no other purpose. Technically, the trust anchor doesn't have to ... 6 What happens when such a device is lost (fire, electronic fault, stolen, etc)? Assuming the HSM is stolen: The CA will likely inform the police so they can hunt the thief down, then they will ensure that the thief has actually only stolen a brick (that is, they can't do anything useful with the HSM) and finally they will just continue business as usual ... 6 Signature generation is not encryption with the private key. Still, the basic flow of what you describe is correct for signature generation. However, the verification step is where everything derails. As indicated in the comments, it is impossible to reverse a cryptographic hash. However, for signature verification, it is assumed that the verifying party ... 5 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 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 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 friends.... 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 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, ... 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 But if Server’s certificate is checked sucessfully by Client, how is it possible to consider that Server has been authenticated by Client, while at this time none message signed with Server’s private key has been sent to the Client and verified by it ? If only consider the key exchange to be what the RFC says it is, then yes this key-exchange can be ... 4 The purpose of the bitcoin block chain is to provide an imitable public ledger. If you read the original bitcoin paper you will see that the block chain is but one component of a larger whole that provides public trust that coins were not double spent. See section 2 "Transactions" that states this explicitly. Within a traditional bank the ledger is ... 4 Is HIMMO For Real? ... I've not been able to find any critiques of the approach. First up, let me quote the HIMMO website itself which described it as broken at the time you asked your question: HIMMO has been shown to have limited collusion resistance capabilities... Beyond that, several papers - describing potentials but also weaknesses - have been ... 4 Spelunking through https://crt.sh, one finds a CA certificate for RSA Data Security, Inc., from 1994, but the oldest certificate it has issued has a validity period starting only on 1998-02-13. That doesn't mean that that CA didn't issue certificates before—maybe the records in crt.sh are incomplete. Indeed, pursuing the PostgresQL interface doesn't reveal ... 3 It is not safe at all since Factoring as a service project (https://github.com/eniac/faas) together with Amazon EC2 allows the factorization of a 512-bit key for less than$100 in only a few hours.

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 (...

3

Alice sends a CSR (certificate signing request) to the CA, which contains her public key, her name and usually her location. This CSR is then signed to prove ownership of the associated private key. The CA uses the data in the CSR to derive a certificate which will be handed to the user afterwards. The user can then prove his identity. The CA needs to "know" ...

3

Great question. I'll answer it in several parts. Which Keys does Alice send? There are two cryptographic operations that Alice may want to do: encryption/decryption, and signing/validation. You can either use the same keypair for both, or have two separate pairs of keys. 1 keypair method: Here Alice would sign outgoing messages, and decrypt incoming ...

3

FIPS 197 is the AES specification. An implementation complies with it if, and only if, it correctly implements the AES algorithm. The standard applies only to implementations of AES; it doesn't apply to certificates, or TLS server configurations, or computer systems in general. In particular, since it only applies to implementations of AES, it doesn't ...

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