New answers tagged

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


0

Yes, you're still secure. The current RSA PKCS#1 v1.5 signature scheme is still thought to be secure. So the following information in RFC 3447 section 8.2, describing PKCS#1 v2.1 still applies: Moreover, while no attack is known against the EMSA-PKCS-v1_5 encoding method, a gradual transition to EMSA-PSS is recommended as a precaution against future ...


2

You're fine. There are several different padding methods listed in PKCS v1.5. The method that has active attacks is actually a padding used during public key encryption - that is, it's used to encode the plaintext message before handing it off to the RSA public function. We don't use that method to sign messages. For that matter, the attack model used ...


2

No, you do not add the ASN.1 encoding to the hash when generating an ECDSA signature. There are two reasons for this: The first is that there is no room, if we select a curve and a hash with equal security. To be secure against attacks that take $O(2^N)$ time, a curve needs to have a prime that's at least $2N$ bits; to be secure against collision attacks ...


3

There is no difference. The wiki page you referred to contains examples of hashes for all three versions of Whirlpool. For string "The quick brown fox jumps over the lazy dog", the current version should produce the following hash: B97DE512E91E3828B40D2B0FDCE9CEB3C4A71F9BEA8D88E75C4FA854DF36725F ...


1

Ok. I think I will attempt answering this myself. Given that (at least on linux), perl, openssl have gone down the same path as the rhash author (I am not sure who in fact, implemented this first), the reason for a different digest, is that, due to restricting the input message from $2^{512}$ bits to $2^{64}$ bits max, the first $512$ rows of $4 \times ...


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



Top 50 recent answers are included