# Tag Info

## Hot answers tagged non-repudiation

69

These types of cryptographic primitive can be distinguished by the security goals they fulfill (in the simple protocol of "appending to a message"): Integrity: Can the recipient be confident that the message has not been accidentally modified? Authentication: Can the recipient be confident that the message originates from the sender? Non-repudiation: If ...

11

There's an obvious solution using DH: Alice has a private key $a$ and a public key $g^a$; Bob has a private key $b$ and a public key $g^b$. When Bob sends a message, he computes the shared secret value $(g^a)^b$, converts that into a MAC key (possibly using a nonce to prevent key reuse), computes the MAC of the message, and sends the message and the MAC (...

9

To complete what @CodesInChaos explains: If the server has a RSA key in a certificate which is suitable for encryption, then anybody can forge a completely fake conversation without the server being involved at all. In the SSL/TLS protocol, when using a "RSA" cipher suite, the client generates the random "pre-master secret" which it then encrypts with the ...

9

The server doesn't sign the data itself. It only signs part of the handshake if you're using a signing based suite. That means you can prove to a third party that a handshake with a certain server happened, and what data was exchanged in that handshake. If you're using a RSA encryption suite, it doesn't even sign the handshake, but authenticates indirectly ...

5

What you want is exactly one of the use cases of ring signatures. A ring signature scheme allows you to choose an ad-hoc group of public keys and compute a signature in such a way, that it could have been created by any holder of one of the corresponding secret keys but by nobody else. The privacy of the construction from the paper linked above is perfect. ...

4

No. Cryptography alone cannot solve this problem. Solving this problem requires a combination of technical (e.g., cryptography, systems security) and non-technical (e.g., legal, regulatory, contractual) solutions. Even the technical part is not solely a cryptography question; it as much about systems security.

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

I found the original question vague/ambiguous but the Bitcoin example is concrete enough to answer. In short, what you want is impossible without relaxing some of your requirements. One of the many requirements you list is that Alice, essentially, has no signing power and can only perform password-based authentication. This is problematic for a fundamental ...

2

With asymmetric cryptography, the sender is not able to encrypt it such that the receiver could have encrypted it without disclosing a private secret without performing a symmetric key exchange. Once you exchange a symmetric key however, you could symmetrically encrypt the contents of the message and the MAC and then encrypt the shared key with the public ...

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

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

1

You can use the well established TLS (Transport Layer Security) protocol to achieve the first three properties and modify it to include a digital signature for non-repudiation*. However, strictly speaking, non-repudiation requires the use of certificates from a CA so that the signature can be verified by any third party.

1

Here's another idea, which seems to be quite similar to poncho's solution, but uses RSA keys: Bob writes his message $P$, creates a random symmetric key $K$ and uses a MAC to calculate a MAC tag $T$ for the message. He signs only this key $K$ with his private RSA key, and also encrypts it with Alice's public key. The transmitted message consists of the ...

1

AES or DES/TripleDES are just primitives. These primitives aide in building the properties of the system you were describing. The 5 properties are that of the system but not a single algorithm. We need a combination of crypto algorithms sometimes to achieve these properties in certain setup. Few examples, Confidentiality of data-in-transit in a "...

1

A theoretical concept for that is covered by so called contract signing protocols. There are quite some research papers into this direction, such as the seminal paper and follow up works in the field of (optimistic) contract signing. For instance, this one or this one. Such protocols always involve a trusted third party, although this party might not be ...

1

I think destroying the private key and using a notary could be some kind of solution to that problem. Both Parties create a private and public key. The public keys are signed by a CA. Both parties sign the document with their private key. After signing the document both parties destroy their private key. After step 4 nobody can claim that he lost the ...

1

There's no way in OpenPGP to MAC a message. You can sign it, but that's it. We could have a lively debate about the legal ramifications of a digital signature, and I'll take the side that it means less than you've been told it has. Like everything, context matters. I could give you a use case where there'd be an approximately 100% likelyhood that a digital ...

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