Hot answers tagged

3

I'm trying to get my head around how the crypto solves this problem. It doesn't. You need to trust the platform you use to do the signing. For instance, my bank has replaced the "signature" generation device that I previously used with one that displays the actual transaction, so I don't have to trust the information on the computer screen that much.


3

No you can't prove that C sent something. The only thing you can reliably prove to somebody is that somebody at some point had a HTTPS connection to C, by presenting the key exchange. You can't prove that C send something because the record layer is symmetrical, meaning everything C sent, could be forged by B as he has to have the neccessary keys. To ...


2

There are only two messages from the client before TLS permits the server to send Application Data; ClientHello and the other one, in that order. ‚Äč Furthermore, the client does not keep any secret randomness between ClientHello and that other message from the client. Thus, the third party can use the following strategy in an attempt at breaking ...


1

Can anyone suggest an example of an application where we need to know who sent the data but it doesn't really matter if they later deny that they sent it? I would argue that most situations where you need authentication are like this. You very rarely need to be able to prove anything to third parties. For example, if you have a TLS connection to a ...


1

First, there is no way that crypto can keep an attacker from manipulating the data that is shown to the user. to prevent this, you have to trust some part of your hardware, at least the screen that views the data and some chip inside that can do some crypto. Moreover, digital signatures alone will not solve this problem as the merely capture signing a ...



Only top voted, non community-wiki answers of a minimum length are eligible