# Tag Info

0

In RSA systems one type of attack is based on the multiplicative property of RSA. Suppose that $y_1=\operatorname{sig_k}(x_1)$ and $y_2=\operatorname{sig_k}(x_2)$ are any two messages previously signed by A. then: $$\operatorname{ver_k}(x_1\cdot x_2 \bmod n,y_1\cdot y_2 \bmod n)=true$$ In this case for avoid this attack, instead of message we can sign ...

0

Just as someone uses a public key, they would also display their hash function. The hash function will make the message smaller, and it also adds security so that keys cannot be forged. Adding a hash function to public key crypto is just an added layer of security.

0

First of all signing does not equal encrypting. It only works on some crypto systems and even then it is not the whole picture. Hash algorithms are used for various reasons. One of them is to reduce the size of the signature since the digest is generally a lot smaller than the message itself. But the main cryptographic reason behind hash functions is to ...

2

Or does OpenSSL derive the IV by the decryption key somehow from the packet ? Well, yes. Actually, it's not that complicated; for DTLS and AES-CBC mode, the IV is the first 16 bytes of the encrypted region, so it just reads it from there, and starts decrypting from there. In DTLS, we assume that encrypted packets can be dropped in flight (or received ...

5

The SNI extension is plain text in the ClientHello. This means that it is possible to passively snoop the value and redirect the traffic. This is already used in practice, i.e. haproxy has this feature for several years.

6

No, TLS is not secure against VM reset attacks. There are at least two attacks that are made possible by VM reset attacks, off the top of my head: AES-GCM nonces are typically generated deterministically from the message counter value. If you set the snap shot prior to the local peer sending a plain text message that will change after resetting to the snap ...

0

If you break this down in terms of a client/server relationship I think it may offer some insight. TLS is neither explicitly or implicitly vulnerable and, like you said, it depends on the implementation. For example: if the server utilizing TLS is virtualized, then rolling back to that point may introduce a replay. But if you’re talking about client ...

7

No, you can't; the reason you can't depends on the negotiated TLS ciphersuite: The original ciphersuites had the server send to the client the server's RSA public key; the client selects a random value ("premaster secret"), and encrypts that value with the server's public key; it sends that encrypted value to the server. Now, these public keys have the ...

1

It doesn't seem that openssl is capable of doing this itself, especially against servers that don't advertise RSA-MD5 support but will still accept it (e.g. OpenSSL pre-1.0.1e). But see https://securitypitfalls.wordpress.com/2016/01/06/testing-for-sloth/ which appears to provide a handcrafted TLS1.2 client that will test for the broken behaviour. I haven't ...

Top 50 recent answers are included