New answers tagged

0

@dave_thompson_085 According to this link https://blogs.msdn.microsoft.com/dsnotes/2015/12/03/authenticated-encryption-capi2-does-not-support-authenticated-encryption-mode/ Crypto API’s or CAPI2 does not support authenticated encryption mode. This means there are no API’s in CAPI2 that can be used to implement authenticated encryption. It can only be done ...


6

Yes, the basic idea of hardcoding a public key is secure. It is sometimes recommended as an alternative to the complexity TLS and PKI bring – otherwise it can be easy to skip a crucial step and end up with little or no security. However, the "encrypt a secret for server" scheme has some weaknesses compared to TLS. The clearest is lack of forward secrecy ...


4

rfc5246 7.4.9 defines verify_data as PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1]; Note the second line; this effectively truncates the PRF output to verify_data_length octets. It goes on to say that verify_data size depends on the cipher suite. Any cipher suite which does not ...


1

A TLS session can be resumed once both sides know of the session. The exchange of the necessary information (i.e. session identifier or session ticket) is done within the initial handshake. This means a session can already be re-used within other connections once this initial handshake is done. How long the session information are kept and if they are ...


2

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 ...


4

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 ...


1

I want to answer the third question, as all other questions are brilliantly answered. In TLS handshake as in diagram: In DH/ECDH, the "ServerKeyExchange" message will be empty since the value g^x is already present in certificate. This can save server a lot of computation. This will be a advantage in servers with heavy load and save time in CPU ...


0

There is typically no private key on the client side. At a high level the process goes something along the lines of (this is a simplification, read the protocol specs if you want the fine details) The client sends the server a "hello" message with info on supported protocols and ciphersuites. The server chooses a cipersuite and protoocol version and sends ...


0

While there are many TLS configurations, I will describe the most common setup. The public key is fixed on the server side - it is the servers public key. Upon connecting to the server and receiving the public key, the client then validates the key by checking that it has not expired, that it matches the domain name of the server who sent it, and most ...


1

No, there are no problems (which I could see) with re-using the signature key in this scenario. There are two potential concerns: It may be possible to learn something about the private key using the challenge-response protocol It may be possible to re-use the signature of a run of the challenge-response protocol for TLS The first concern is clearly ...



Top 50 recent answers are included