164
File extensions can be (very) loosely seen as a type system.
.pem stands for PEM, Privacy Enhanced Mail; it simply indicates a base64 encoding with header and footer lines. Mail traditionally only handles text, not binary which most cryptographic data is, so some kind of encoding is required to make the contents part of a mail message itself (rather than an ...
74
SSH not using TLS is mostly historical; see for instance this answer (on security.SE). In practice, one could perfectly define a sort-of SSH that would use TLS for the data transport part; but, of course, it would not be compatible with existing SSH servers and clients. From a pure cryptographic point of view, SSH actually has some shortcomings with its ...
63
I believe there are three main reasons why ChaCha20 is sometimes preferred to AES.
On a general-purpose 32-bit (or greater) CPU without dedicated instructions, ChaCha20 is generally faster than AES. The reason for this is the fact that ChaCha20 is based on ARX (Addition-Rotation-XOR), which are CPU friendly instructions. At the same time, AES uses binary ...
62
Diffie-Hellman Key Exchange
Problem: We have a symmetric encryption scheme and want to communicate. We don't want anybody else to have the key, so we can't say it out loud (or over a wire).
Solution/Mechanics:
We each pick a number, usually large, and keep it a secret, even from each other. I'll pick $x$, and you'll pick $y$.
We agree on two more numbers,...
54
Well, yes and no.
Triple DES using 3 different keys is still considered secure because there are no known attack which completely break its security to a point where it is feasible nowadays to crack it.
The Triple DES algorithm provides around 112 bits of security against bruteforce attacks (when taking into account the meet-in-the-middle attack).
For ...
48
Short: CBC mode in context of TLS protocol has had security issues, and would have had to be reworked.
AES-CBC mode combined with decent HMAC can be as secure as AES-GCM. However, combining the cipher and MAC securely has been in practice found to be much easier said than done. Also, padding that is required by AES-CBC mode complicates things.
In ...
47
If by TLS, you mean specifically the series of protocols that is named "TLS", then the answer to why SSH wasn't designed to use them, is quite simple: they didn't exist when SSH was designed. TLS was released in 1999, SSH in 1995.
If you are referring to the whole family of protocols that is now known as TLS but used to be known as SSL, then the answer is ...
36
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. ...
32
Simplified SSLv3/TLS from this book Note, $R_{(Alice|Bob)}$ is a random nonce chosen by Alice or Bob respectively, and $\{S\}_{Bob}$ is encryption with Bob's public key.
pre-master secret
As stated in one of the answer you link to, "The point of a premaster secret is to provide greater consistency between TLS cipher suites."
In the figure above, the ...
25
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.2 Appendix A.1.2 (likely restricted to version 0). It decodes to:
30 ASN.1 tag for ...
25
In practice, in situations like TLS, public key encryption will be used to encrypt a secret for encrypting the actual messages, as part of a hybrid cryptosystem. This is done because Asymmetric cryptography is significantly slower than symmetric cryptography.
However, there are other cryptosystems and applications that utilize public key encryption ...
25
It seems that PGP certificates have the problem that they can be changed by the user. Furthermore, there were extensions for 1.2 that are incompatible for 1.3 (if they were secure in the first place):
I found this on the TLS mailing list from Ilari Liusvaara:
Ugh, the situation is way worse than what I thought.
Basically, all three assume they have ...
23
AEAD cipher implementations are generally encrypt-then-authenticate internally (while the CBC ciphers in OpenSSL were not). TLS really was in need to get rid of the authenticate-then-encrypt which required special handling of the CBC code for block ciphers such as AES. The AEAD ciphers - regardless of the internal structure - should be immune to the problems ...
23
why the SSL is not under the TCP ( Transport layer ) ?
Because SSL can use TCP [1] to transport SSL records, and so SSL relies on TCP as a service.
That is, SSL takes the user data stream, and converts it into a series of records; it then gives these records to TCP to transmit. On the other side, the receiver's TCP stack gets these records and gives it ...
22
Since this is still open and the issue keeps coming up:
TLDR: There are lots of things in OpenSSL that implement standards including AES, but the key derivation part of enc is partly nonstandard (at least by default)
First, OpenSSL has several commandline operations it calls commands (although they usually aren't separate programs, as typical commands are on ...
22
Forward secrecy is a confusing term that should be abandoned, especially the meaningless but value-loaded variant ‘perfect forward secrecy’. It is especially confusing because it is often associated with any protocol that does ephemeral DH key agreement, like TLS—even if, as in TLS<1.3 session resumption, the keys capable of decrypting transcripts of ...
21
I'll quickly decompose this cipher suite.
TLS - standard starting point
ECDHE - elliptic curve version of the Diffie-Hellman key-exchange using ephemeral keys (/exponents), other values for this position include RSA, DH and DHE
ECDSA - signature algorithm, used to sign the key-exchange parameters, omitted for RSA, other values include RSA
AES_128 - AES with ...
18
Unless we find information from Google - such as white papers & mailinglist posts - we can only speculate why ChaCha20 is chosen. I think that efficient software implementation is still the most likely reason. That AES-GCM is relatively brittle - for instance with regards to timing attacks - could be another.
Note that even though AES-NI is becoming ...
17
TLS 1.3 is a reboot of the TLS protocol which focused on up to date cryptography rather than backwards compatibility.
Now CBC is not as secure as you make it to be, and the way that it was used in TLS made it particularly vulnerable. To note: in TLS the HMAC authentication tag was created over the plaintext rather than the ciphertext. This made TLS ...
16
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 ...
16
The rationale goes this way:
On a "big" system like a PC or a smartphone, ChaCha20+Poly1305 or AES/GCM are very efficient; the latter is fast because the hardware provides dedicated opcodes that implement both AES itself (aesenc, aesenclast on x86 CPU) and the GHASH part of GCM, which is used for the integrity check (pclmulqdq opcode on x86 CPU).
On much ...
16
Salt-less password hashing is only a problem since the amount of passwords actually used in practice is comparably small and also not evenly distributed. Thus it is both in terms of time and memory possible to generate a table with pre-computed hashes and then check the salt-less hashes against this table to reverse the hash. The protection against this are ...
15
Short answer:
There would be nothing (that isn't already wrong with TLS) necessarily wrong with a CTR + HMAC cipher suite, but the technical merits are only one factor in a technical feature getting to RFC status in the TLS working group.
Without being discourteous to the TLS Working Group (WG) participants or process, other reasons can be: political (...
15
TLS 1.0 uses initialization vector (IV) to refer to two different processes. TLS 1.1 introduces a new type of IV that causes an entire block to be discarded and isn't directly comparable to the old series of IVs based on CBC residue. By simply changing an operation at the beginning of a record, the hope was apparently to make implementations easy to patch ...
14
Short answer: Because the browser developers have long thought interoperability to be more important than security and standard compliance.
Slightly longer answer: Some SSL/TLS server implementations do not negotiate the protocol version correctly, but terminate the connection with a fatal alert if the client attempts to negotiate a protocol version that ...
14
The point of a premaster secret is to provide greater consistency between TLS cipher suites. While RSA cipher suites involve the client sending a random 48-byte premaster secret directly to the server, other suites do more complex things to generate the secret, and end up with a secret that might have some structure to it. For instance, (EC)DH suites use (...
14
What is the advantage of AEAD ciphers?
That depends one the scheme, but often it means you:
Trust only one algorithm, not two.
Perform only one pass (an ideal in the world of AEAD, not a consequence of it).
Save on code and sometimes on computation as well.
The code savings can matter in embedded and IoT settings.
Why is the TLS working group pushing ...
13
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 and the ...
13
A PRF or pseudorandom function family is a family of functions $F_k\colon \{0,1\}^n \to \{0,1\}^m$ such that if $k$ is uniformly distributed, then $F_k$ appears to be uniformly distributed among all functions $G\colon \{0,1\}^n \to \{0,1\}^m$. A PRF $F_k$ is secure if an adversary who does not know the key $k$ can't distinguish $F_k$ from a uniform random ...
answered Aug 15 '17 at 15:36
Squeamish Ossifrage
44.3k3 gold badges94 silver badges193 bronze badges
13
(1) I'm curious whether the following 10 different DH Groups are the only groups that TLS 1.3 supports,
Yes, in the sense that TLS 1.3 only allows groups that are explicitly declared as supported in 1.3. This currently includes not only the groups from RFC 8446, but possibly more recent RFC as well, such as Brainpool curves from RFC 8734.
The TLS supported ...
answered Jan 17 at 17:09
Gilles 'SO- stop being evil'
15.3k3 gold badges40 silver badges78 bronze badges
Only top voted, non community-wiki answers of a minimum length are eligible