Tag Info

Hot answers tagged

8

Is it true the longer the key length is the more secure the encryption? No. Key length does put an upper bound on security, because it determines the complexity of brute force iteration of the key space or factoring, discrete log, etc. for some asymmetric algorithms. However, once you have a long enough key to make brute force attacks impossible, there ...


7

There's no real difference between $p$ and $q$ in RSA. It looks like OpenSSL just has the agreement "$p$ has to be bigger than $q$" for conveniences. One of the numbers has to be bigger than the other (otherwise they would be the same number, and $p = q$ is very bad in RSA). Just use two examples: $p = 13$ and $q = 11$. $p$ is bigger than $q$, all right. ...


7

Copy / paste that key into http://phpseclib.sourceforge.net/x509/asn1parse.php and you'll see that there are several different integers in there. p is there, q is there as is the exponent and several other integers to speed things up by taking advantage of the Chinese Remainder Theorem. The key is encoded using DER and derives semantic meaning via ASN.1. ...


6

In a better world, TLS_FALLBACK_SCSV would not be necessary: SSL has been supporting downgrade-proof version negotiation since at least SSL 3.0, so a man in the middle should never be able to limit a connection to a version older than the mutually supported maximum. However, out there are some broken servers that don't really support that kind of version ...


6

I don't know about computing things in parallel, so I will ignore that part of the question. First, please note that the encryption algorithm is rarely the the weak point of the security. It is far more likely that you will have problems with the implementation, some spyware installed on your computer, a weak password (If you use qwerty as your password, ...


6

The main thing that makes HMAC secure in typical use even with MD5 is that it is used with a secret key. That means only preimage attacks are really relevant, since finding a collision is always an online attack if you don't know the key. With known attacks the preimage resistance of both MD5 and SHA-1 is > 100 bits. Additionally, HMAC may be secure even ...


6

To make it easier for humans to read.


5

First, I am assuming, per https://security.stackexchange.com/questions/29172/what-changed-between-tls-and-dtls, that the client handshake protocol in DTLS is not different from that in TLS over TCP. This seems a safe bet since the client/server encrypted handshake protocol in OpenVPN's UDP implementation is the same as in standard TLS over TCP. I am not ...


5

From RFC 5246, section 6.2.3.3: AEAD Ciphers: AEAD ciphers take as input a single key, a nonce, a plaintext, and "additional data" to be included in the authentication check, as described in Section 2.1 of [AEAD]. The key is either the client_write_key or the server_write_key. No MAC key is used. However in RFC 5246, section 5: HMAC ...


5

It is correct that the given private key does not encode a single integer, and that it includes two primes $p$ and $q$. More precisely, that Base64 data encodes a string of bytes, which is an RSAPrivateKey encoded per ASN.1 DER-TLV (and thus BER-TLV) following PKCS#1v2 Appendix A.1.2 (likely restricted to version 0). It decodes to: 30 ASN.1 tag for ...


5

Designing your own crypto protocol (using existing primitives) is dangerous if you're not sufficiently familiar with cryptographic protocol design and the ways such protocols might be attacked. If you wish to gain such familiarity, I'd recommend taking a few introductory crypto courses that focus on protocol design and analysis.* This won't turn you ...


4

Well, it is certainly possible to generate an RSA public/private key pair like what you're asking about -- I don't know what the OpenSSL API allows you can do, but if you don't restrict yourself to that, well, it is certainly possible to craft such a keypair. You'll come up with a public key with an enormous exponent (and I wouldn't be shocked if not ...


3

Like all things in life, there are tradeoffs to be balanced. SSL can use RSA keys, right? So why not generate 2 billion bit RSA keys? Well, the efficiency of RSA goes down significantly as more bits are added. With too large of keys, RSA would be impractical to use in real life. Another answer to your question is that 5000-bit AES does not exist. We are ...


3

I do not know why the OpenSSL implementation specifically does this. However, a branch-less (constant time) implementation of the RSA private key operation, might be slightly more efficient if the parameter $c = q^{-1} \bmod p$ is calculated for $p$ being the greatest prime of the two. Otherwise the value of $J_q = I^{d \bmod q-1} \bmod q$ has to be taken ...


3

The certificate makes sure that whoever you're talking to is who they claim they are. With TLS/SSL without certs you wouldn't notice if you're communicating with an impostor over an encrypted channel instead of whoever you're expecting to communicate with. This leads to so called man-in-the-middle attacks. You really should read this, if you're going to use ...


3

So that the server knows who you are. After all, TLS protects the communication; however anyone can initiate a TLS connection to the server (unless the server insists that client authentication must be used; they rarely do). So, if the server needs to make any decision based on who the client is, it needs to find that out itself; TLS usually won't provide ...


3

Symmetric algorithms are secure post-quantum, only with less bits of security (usually about half). That means you only need to care about the authentication and key exchange parts of the cipher suite. Suites that don't use public key authentication or key exchange, i.e. preshared key suites, are post-quantum secure, but not useful in most usecases. There ...


3

In TLS, the key exchange step results in a key called the master secret which is then derived into as much key material as needed with a custom key derivation function, called in TLS terminology the PRF. It is not slow -- contrary to PBKDF2, the "PRF" of TLS is not for handling password and thus has no need to be slow.


3

Feasible? Sure, there are lattice algorithms that are competitive in performance with RSA. However, there are drawbacks, like: They've been studied less than RSA or ECC, especially the individual algorithms. The most well studied system, NTRU, is patented. No generic proof that I know of that there isn't a quantum algorithm to solve them. The first one ...


2

If the application completely trusts the public key (e.g., runs code signed by it), then you could add "master key change" messages that can be signed by it, that make the application change it's hard-coded key. For additional security, you could require that the new key be additionally signed by a key hopefully separated from the now-compromised one - here ...


2

Assuming this is "usual" HTTPS using SSL/TLS with RSA key exchange, the client generates a random secret, encrypts it with RSA (using the server's public key) and sends it to the server. The server then decrypts it (using its private key), and both generate from this (now shared) secret (and some public data depending on the messages) several keys which are ...


2

The answer to the first question is both. TLS uses a custom PRF based on HMAC to generate symmetric and MAC keys from a shared secret. The shared secret is created during the asymmetric key exchange between client and server as part of the handshake. The PRF generates key material of a required length. That length is determined by the key sizes and the key ...


2

Yes, the MAC algorithm works the same way on both sides. It is a mathematical function that computes the tag from the key and the message. On the sender side, the message is processed as follows: Calculate T = MAC(key, raw_message). Send the raw_message and the tag value T. Many communication protocols append them in this order but anything will do as long ...


2

SHA is related to AES in that they are both US government standards. They are not similar algorithmically. SHA and AES are cryptographic primitives, TLS is a protocol. As the name describes SHA is a family of hash algorithms. AES is a block cipher. TLS uses many encryption algorithms, including AES in various modes, and several hash algorithms, including ...


2

Short answer, before someone marks this as a duplicate or answers it with an essay or something: You're exactly right. This was one of the biggest consequences of the infamous Heartbleed exploit in OpenSSL, which exposed the memory of processes using OpenSSL for TLS to anyone with an Internet connection. It's also significant for cold boot attacks, where ...


2

I need a small clarification that why openssl using SHA1 in ECC when I am using secp384r1 curve, but in rfc they are saying we should use SHA2. OpenSSL uses SHA-1 because RFC 4492 defines the use of ECC on SSL with SHA-1. It should also support SHA-384 as defined in RFC 5289. Which hash algorithm is used in TLS depends on the cipher suite. For example: ...


2

They rely on problems not so different as you might think. They are based either in the factoring problem or in the discrete logarithm problem, which have a deep connection between each other. Once you have an algorithm that can efficiently solve one, you most likely would be able to adapt it to reproduce an answer for the other in polynomial time. Thus ...


2

TLS 1.0 is in effect SSL 3.1. If you need more details about the history and why it is called TLS 1.0 instead of SSL 3.1 read Wikipedia.


2

Aren't $IV_1$ and $IV_2$ public in TLS 1.2 as well? $IV_1$ certainly is (as that's just the ciphertext block in front of the block we're attacking); however the IV that the TLS 1.2 sender will use for the next message ($IV_2$) is not. In fact, the sender might not know it yet, as it might not have not picked it yet. But doesn't this mean that BEAST ...


2

SSL padding always pads, using 1..blocksize bytes (8 bytes for triple DES, 16 for AES). This padding makes it deterministic independently of the value of the plaintext. It's a padding mode similar to ISO 10126 (only the last padding byte is one less). Other padding values - such as the zero padding performed by PHP's mcrypt library - are also ...



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