New answers tagged rsa
0
It means that the cryptography from the certificate is breakable - the ROBOT attack is a good write up on how. ECDHE uses elliptic-curve cryptography, which is faster, uses less data for the same level of security, and relies on newer mathematical techniques (although it's not necessarily a good thing...but as a quick aside ECs were needed for solving ...
0
Hard to know, but it is probably only product references. One way to check would be a pattern, like the same first numbers for two devices. If it is indeed serials, the only way that could impact you is if someone could somehow go to RSA and check if they have records of matching ids and private seeds. So, unlikely to happen.
You could also think that the ...
3
The use of the private key cannot reasonably be called “encrypting” since the security objective is to ensure authentication, not confidentiality. There can't be any encryption going on since all the information to reverse it is public. What you describe is a signature scheme, specifically a signature scheme with recovery since the same encoded message ...
2
YES -- there is no necessary connection between the types of keys and certs used by TLS server and client for authentication (nor between the Certificate Authorities and trust decisions).
For TLS versions through 1.2 (and SSLv3, which no one should be using now), the server key-and-cert must match the key exchange portion of the ciphersuite used, which the ...
3
Yes, it does mean exactly that that.
The pre-master secret in this protocol is a random generated by the client. It is simply encrypted using the public key from the certificate at the client and decrypted by the server using the corresponding private key. The pre-master secret is then used to calculate the master secret and the session keys.
The Finished ...
3
(CW for anyone who wants to add additional cases)
The size/strength of ephemeral keys for DHE and ECDHE key exchanges in TLS can depend on
the protocol (version)
the server-side implementation code (usually a library), and sometimes configuration
the client-side implementation (ditto)
First, there is a significant difference between TLS 1.0 through 1.2 (...
1
The specific curve or DH key length is not given in the cipher. The client simply supports a number of curves and can give these in the ClientHello (elliptic_curves extension), similar to how the client shows the supported ciphers. Similar the server has a number of curves and specific DH param configured and can align these with the curves offered by the ...
0
For your problem, the easy way coming to my mind is PGP: both the sender and the receiver exchange asymmetric keys and can then send each other private messages. You can validate each other pulic key other the phone to make sure no one messed with it (see MitM).
For all I know, using WhatsApp or Telegram might also be secure enough as they use end-to-end ...
1
It should be secure if used correctly, however, using raw RSA correctly is a difficult task. Because it is easy to make a critical mistake, using low level primitives is discouraged and considered bad practice. You should get a high level library with simple API if possible.
If you can't, make sure you read up on RSA padding and all the peculiarities of RSA,...
0
I had to remove my answer because it was flat out wrong: the PKCS#1 v1.5 scheme for signatures used by OpenSSL is only used partially (thanks Dave for yet another insightful comment). That also means that is doesn't hash the input - but that means that it doesn't fully respect the security claims of PKCS#1 v1.5 and upwards either for that scheme. So it ...
0
Traditionally in SSL/TLS the client chose a master secret and encrypted it with the RSA key from the server's certificate. This is the approach used by the traditional RSA ciphersuites.
However the problem with this approach is that it if the server's long term private key is ever compromised then at attacker can passively decrypt the traffic. In particular ...
Top 50 recent answers are included
