122
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 ...
73
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 ...
58
I believe there are three main reasons why ChaCha20 is sometime 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, while AES uses binary fields for the ...
57
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,...
53
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 ...
46
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 ...
44
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 ...
40
1 - How feasible is it that the chip's manufacturer can predict the output of this PRNG when it passed tests from the people applying the use of this RdRand instruction in kernels?
A strong stream cipher's output is random and unpredictable to anyone not knowing the key. See where this is heading? Just because something looks random doesn't mean it's random....
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
In the beginning SSL handshake, the client sends a list of supported ciphersuites (among other things). The server then picks one of the ciphersuites, based on a ranking, and tells the client which one they will be using.
This step is the one that determines whether or not the future connection will have perfect forward secrecy. Note that, at this point, ...
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 ...
24
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 ...
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
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 ...
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
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 ...
20
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 ...
20
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 ...
19
The reason why you see that is because Camellia is the highest-preference cipher in NSS (Chrome and Firefox). Servers that support Camellia and use the client-preferred cipher suite will use Camellia.
NSS's rationale for this ordering is:
National ciphers such as Camellia are listed before international
ciphers such as AES and RC4 to allow servers ...
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
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 ...
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
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 ...
15
Have you heard of the strange story of Dual_EC_DRBG? A random number generator suggested and endorsed by the government that exhibits some very suspicious properties.
http://www.schneier.com/blog/archives/2007/11/the_strange_sto.html
From that article:
This is how it works: There are a bunch of constants -- fixed numbers -- in the standard used to define ...
15
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 ...
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
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 (...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
