4

I have message (m), and I want to store some data to verify its integrity after sending it by an insecure way..

I can create a digital signature (DSA / RSA).

  • S(m) = digital signature of m.

Or I can calculate a digest (hash) and cipher it.

  • H(m) = digest of m
  • C( H(m) ) = ciphered data of H(m)

In any case, when the receiver gets the message should verify its integrity.

What method is more secure S(m) or C( H(m) )?

UPDATE

Suppose Alice want to send a message to Bob

Using digital signature:

Alice's part:

  • Compute S(m) using her private key
  • Send m, S(m) and her public key to Bob

Bob's part:

  • Bob receive S(m), m and Alice's public key
  • Bob verify the S(m) using m and Alice's key.

Using digest:

Alice's part:

  • compute C( H(m) ) using Bob's public key
  • send C( H(m) ) and m to Bob

Bob's part:

  • decipher C( H(m) ) using his private key (d)
  • compute H(m)
  • verify integrity of m ( H(m) = d )

I saw a software using the second method I posted, but I think the first one is more secure, am I right?

UPDATE 2

In conclusion, the best way is to use the first method sharing Alice's public key with Bob using a secure way.

The second method provide not security at all.

Thanks to @Perseids

AlexITC
  • 1,054
  • 1
  • 10
  • 21

2 Answers2

6

None of them works.

Attack on the first: Eve mounts a man in the middle attack and intercepts all messages send by Alice. Instead of forwarding m she forwards n. Instead of the signature on m with Alice' private key she forwards a signature on n with her private key. Instead of Alice' public key she sends Bob her public key. Bob will never see the difference as he does not know Alice public key beforehand.

Attack on the second: Intercept all messages from Alice (and throw them away) and create the same messages as Alice' did, but with n instead of m. Don't forget to pretend to be Alice.

The root of the problem is that Bob needs to have some kind of understanding who Alice really is. If you know nothing more of "Bill Gates" than his name then it easy for me to impersonate him. The standard assumption for digital signatures is that Bob knows Alice' public key from a secure source or that they have exchanged it previously over a secure channel. Then Bob can check Alice' signature against the - known to be good - public key of Alice.

Perseids
  • 12,584
  • 5
  • 40
  • 64
  • In the first method, If Bob have Alice's public key and Alice send only signature and message, Is more secure, isn't it? – AlexITC Jul 29 '14 at 17:07
  • @vhax: Yes that is sufficient. – Perseids Jul 29 '14 at 17:11
  • thanks, is there an advantage to use digital signature instead of digest in this schema? – AlexITC Jul 29 '14 at 17:18
  • 1
    Anybody can create a digest, so there is no (direct) method of authenticating the data with just a digest. – Maarten Bodewes Jul 29 '14 at 17:57
  • 1
    @vhax Digital signatures proof that a document comes from a certain party (from someone having the corresponding private key). Cryptographic hashes can be used to identify arbitrary length messages with short, fixed length hashes. The required property is called collision resistance. But in themselves hashes do not provide any authenticity. Specifically, nothing in your second scheme prevents me from impersonating Alice: there is no secret that only Alice possesses. – Perseids Jul 29 '14 at 17:59
  • @owlstead: yeah. anybody can, by that is created and ciphered, I want to know how good can be this versus digital signature. – AlexITC Jul 29 '14 at 18:00
  • @vhax The second scheme provides no security whatsoever. – Perseids Jul 29 '14 at 18:03
0

In the context of digital signatures, a “message” is usually a hash value — that is a digest of some document (“message” in regular sense). So, when you “sign a document” in proper way, you are applying a one-way transform defined by signature algorithm to the digest of that document — not to the whole document.

You may, of course, invent some other means of message authentication, based on symmetric or asymmetric cryptography, or on both of them at once. But thus you will be definitely reinventing the wheel, and chances are very high that your wheel will turn out to be quadruple or so. Digital signature algorithms are specifically designed for seamless authentication within public key infrastructure. So use them appropriately.

Anton Samsonov
  • 1,380
  • 17
  • 34
  • I saw a software using the second method I posted, but I think the first one is more secure, am I right? – AlexITC Jul 29 '14 at 16:40
  • The second one does not look like a correct MAC construction to me, so it is not valid. Otherwise it's up to you to create signatures (using asymmetric keys) or message authentication codes (using symmetric keys). This depends on how you want to implement your key management. – Maarten Bodewes Jul 29 '14 at 18:06
  • @Anton In principle most signature algorithms consist of a hash method, a padding method and a trap door function (i.e. modular exponentiation for RSA). The hash function is *considered part of the signature scheme*. The choice of hash function and padding method are considered parameters of the signature function. – Maarten Bodewes Jul 29 '14 at 18:11
  • @vhax I also saw many “solutions” in real-world software, that is — in established commercial software. Some of those “solutions” may be even standardized industry-wide. But those facts alone do not make those “solutions” any bit less stupid, because they either facilitate cracking to the point of feasibility and affordability, or provide virtually no additional security at all — except against the most unsophisticated users. However, regarding your second scheme, — see my next comment. – Anton Samsonov Jul 30 '14 at 16:46
  • @owlstead Can't agree with you on that the second scheme is not valid. Imagine that symmetric cypher `C(m, k)` relies on a pre-shared key `k` known to both the sender and the receiver. Let's say it's some “installation id” (generated in non-sequential manner) that is known to DRM-protected data supplier and the subscriber's hardware, but not to the human subscriber himself. That way data authenticity may be indeed verified, without employing heavy-weight digital signature math. Of course, it may open possibility for known plaintext attack, so HMAC seems way better. – Anton Samsonov Jul 30 '14 at 16:48
  • @owlstead Hash functions are surely considered a part of signature *scheme* (“sha1RSA”), but not a part of signature *algorithm* in its basic form (“RSA”). Even with DSA, which imposes tight restrictions on digest (“message”) size, you may still substitute hashing function with another one of the same output size — as long as recipient does the same. Only with additional enhancements, like RFC 6979 for DSA, hashing function gets kinda “built into” signature algorithm, but still not too deep, and you still can use other functions to generate the input hash. – Anton Samsonov Jul 30 '14 at 16:52