85
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 ...
71
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 ...
59
I wouldn't assume that the NSA has cracked AES ciphers. I would assume that most crypto systems that use AES have implementation flaws that the NSA exploits when they feel it is worth it.
In any case, when the only possible way a state can know something is by breaking a cipher, it's difficult for them to use that information; doing so would reveal that ...
53
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,...
51
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 ...
51
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 ...
43
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 ...
43
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....
38
An interesting thing about some modern standardized ciphers, like AES, is that the government is "eating its own dogfood" by using them internally. (AES 192 and 256 are approved for top-secret data.) Back in the day (up through the 90s), U.S. government internal encryption standards was not closely aligned with public sector cryptography, and we largely had ...
35
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....
28
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, ...
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
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 ...
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
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 ...
21
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 ...
19
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 ...
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 ...
18
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
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 ...
16
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
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 ...
15
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 ...
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 (...
14
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
