HMAC vs. RSA-SHA

Hi,

With RSA-SHA, you hash the encrypted message, then sign the hash with the private key, and send this with the encrypted message.

To verify, the public key is used to decrypt the encrypted hash, a new hash of the encrypted message is computed by the receiver, and compared with the decrypted hash. If they match, the message has not been tampered with, and if it decrypts properly, is authentic.

Am I understanding that correctly?

If so, is there any point using HMAC, whereby you have to somehow transfer two keys securely to the recipient so they can verify the HMAC?

I know the RSA-SHA is known as a signature, but isn't it achieving the same thing?

Best regards,
AstroTux.

For classic RSA signatures, Alice hashes the message, encrypts the hash with the private key, and sends the result. At the other end, Bob calculates the hash of the message (which is sent plaintext) and then decrypts the encrypted packet from Alice yielding the hash. If they are the same, you know that Alice and only Alice sent the message. If you include a timestamp, then you can prove that Alice signed it at the appropriate time.

With a HMAC, you are using (or effectively using) secret key crypto. One normally does not send the secret that converts a simple SHA to a HMAC. If Bob has the secret, how do you know that Mallet has not stolen it from Bob and using it to fake messages?

Actually, with RSA, there is a chance that Mallet steals Alice's keys, which is what leads to key revocation processes, CRLs and all sorts of other stuff from the X.509 world

As noted elsewhere by Peter Guttman:

OK... so basically they're the same thing, done differently?


W-H-Y-? I can't believe it is for reasons of "too difficult"!

Now you mention it, I've read about PKI for years, yet never actually seen a system that looks like a PKI in use!!

Best regards,
AstroTux.

No, they have different goals. RSA of a HASH is useful without any shared keys. HMACs require a known secret key. Key management is a royal PITA, which is why everyone was so excited about RSA when it was invented.



Taking the last one first, who do you trust? The UN? Me? the US Government?

The prime reason that PKI doesn't exist is political, not technological.

Look at the X.509 standards and the process that makes the standards. The standard is overly complex and unusable because the process had to bang out a compromise acceptable to all parties. And some of the parties were folks like the German Post Office, which was happy getting a small fee for stamps and notary public. With a working PKI, they stop getting the revenue.

Take a fairly innocent real world example: back in 1992 or so when PGP was first hitting the net, and the net was not commercial, so it was a more innocent times, I showed PGP to a friend who was a true believer Christian Evangelist. He promptly showed his missionary friends how to use it, which quickly moved to missionaries in countries where preaching Christianity is illegal.

Ignoring whether or not it is wise to use encryption to prevent the government from reading your email, how can you expect that the X.509 commitee members from that country are going to agree to the use of CAs that are not part of the government? What happens if the government decides that any encryption that it can't break is a clear violation of its laws against things that are important, such as preventing Christianity?

This is not a technological problem. Phil Zimmerman's Web Of Trust provided all the technology needed 16 or 17 years ago.

You may also want to read about "true names" and other hot topics from the early 1990s. Who tells me that AstroTux really owns this key?

(Sorry - I edited my post as I wasn't so sure on some of my comments).

...so why isn't the use of key servers more wide-spread in those countries where it is easier to achieve this? Why do Governments need to get involved in the first place?

Best regards,
AstroTux.

Again, its political or perhaps philosophical.

What does having a key on a key server mean? For example, google MIT, keyserver pfarrell and you will find:
http://pgpkeys.mit.edu:11371/pks/lo...arch=0x275BDA29

What does that mean, really? Is "fishtoprecords" related to this "pfarrell"?
And how many "pfarrell" are there? Does it mean that pfarrell's key is still active? Useful?

Again, it quickly becomes "true names"

If its illegal to say "the king is a fink" then it is clearly illegal to have an encrypted packet that says "the king is a fink".

What's the purpose of all this stuff, anyway?

Here is a view into a porthole. When Internet commerce was being contemplated, there was a real worry that Mallet would register "sears.com" and sucker consumers to spend money there. and the precursors to ICANN had no interest in getting in the middle of the legal battles over who can and cannot run 'sears.com'

While that was always the example, the real concern was smaller places, the CD/record store on the corner, how do you know that its really your local CD/record store?

But even when the commercial CAs were created, none of them were willing to verify that sears.com was owned by sears. So for at least a decade, buying a commercial Cert meant nothing. And even today, it doesn't mean much, and hardly anything of value.

What has happened is that everyone uses SSL/TLS/HTTPS and ignores the certs.

The trust has moved from the CA or domain registrar to the user. You trust ebay, amazon, newegg.

So the real answer as a security professional is to ask:

1) what is the security threat that we are attempting to fix?

Keeping it as generic as possible...

Take a corporate environment. Before a server will accept mail from a client, it checks the user cert to ensure that the user is who they claim to be.

How?

The server has the public key of the client. The client (as part of sending e-mail - forget encryption for now), signs a request for access packet, and the server checks the packet for validity. First, it looks for the clients key. Next, it finds the CRL and checks the key is valid. Finally, it verifies the packet.

Once the server has established everything is OK, it permits that station to send an e-mail.

Because of this system of checking the validity of the sender before permitting e-mail to be sent, and because all out-bound e-mail is digitally signed, people receiving e-mail from this address can be sure the sender is who they claim to be. They can obtain the CRL etc.. from the company's public server, and check the validity, etc..

The server can't be (easily) spoofed (I never say impossible), as the request for the CRL is itself checked. Too many links in the chain need to be broken for it to be compromised (e.g. IP address re-directed, server certificates forged, and client computers tampered with to change all the keys so that signatures are valid throughout the chain).

If the problem you're trying to solve is one of the mail server being sure of who it is talking to before permitting e-mail to be sent, using systems that remove the user from the chain, how else can this be achieved?

Forgetting a world-wide database - people can choose to trust a certain server for a specific purpose (in this case, the recipient of a message can choose to trust the company's CRL certificate, and thus the system).

Like people "just" trust Amazon.com, they could "just" trust the key server.

What I'm getting at is if I trust you enough to ask for your key to send you something, I at least trust your key, too. If I can't trust your key (even though I'm asking you for it to send you something in private), then by implication I can't trust you, either, so fundamentally, the trust is broken.

If I choose to trust you, and your key, then why not the key server? After all, the key is the real part of the security, is it not? A CRL on a server does not serve any real purpose to an attacker, unless they compromised your key as well.

Even if I can't trust you, your key will be valid anyway!

So... ultimately, choose to trust the person, choose to trust their key. The only issue that needs fixing is one of key transfer. Depending upon your level of paranoia, no system in the world can fix that, unless it is face-to-face.

So... why not use the system?

(I hope I made sense).


In the RW: one of remote verification, without seeing the person we wish to verify. Note that initial keys would be generated locally, and initial trust set up in a secure environment!

Best regards,
AstroTux.

That fails to answer the question. You can not talk about threats in general. You have to answer with some level of specifics.

The whole point of security, in the real world or in cyberspace is to make cost of the attack be greater than the value of the target. This works for padlocks on bicycles up to arm guards.

It makes zero sense to protect a $10 CD with an armed guard. It makes no sense to protect a shipping crate full of gold with a simple padlock.



Again, you have to be more specific. Do you mean an RFC complaint Internet mail server? You can't have this kind of security and be RFC compliant. So obviously this is a terrible example.

So what is your real example?



If you, the company, issues the keys and controls the server, you don't need no stinking CRLs. You issue keys to users, and your server rejects anyone it doesn't like, for any reason. If the user needs a new key, you issue a new one.

CRLs are a bureaucratic solution to the general problem. In the real world, you don't need that. I run the server, I write the code, I set the policy. If I don't like your key, I don't accept it. Period. I may tell you why, but more likely I will just return "authentication error" and let you guess why I rejected it.

Telling Mallet "bad key for userid" gives Mallet more information than I want to tell him.

You really have to stop thinking about general issues and standards. There are no viable standards. What problem are you trying to solve? What is your budget for time/money/engineers. Make a solution that meets your needs.

The needs of my company may have something in common with your company, but probably not. Without a requirement for interoperability (which impacts cost/time/effort) I don't care what you do, and you don't care what I do.

Seriously, you (AstroTux) have been asking questions and learning over the past months, but you are coming at this from the wrong place.

Wow, this thread got too long for me to read right now. I search it for two keywords I found the most relevant to the difference between HMAC vs. RSA-SHA and didn't find them: non-repudiation and efficiency.

I tore the standards book up long ago. I'm only sticking with standards right now as I'm not 100% sure what I can change without breaking security (remembering what was said a while ago about using only trusted methods, etc.).


Needs are a requirement for a secure system that is as close to fully automated as possible (including key management).

We own both ends of the system. It's just putting something together that is *secure*. I'm trying to simplify as far as possible, but sticking with solid techniques for what I do use.

The remote computer will be taken into threat environments that we're assuming will be controlled by the attacker (including the communications to our server).

I need to get data between the server and the computer that includes:

* integrity
* authentication (user can NOT be part of this process!)
* passing of additional keys

There are no issues with the other points.

Best regards,
AstroTux.

Anything with RSA will have lots of cpu cycles. If that is your measure of efficiency, then there is no discussion.

But if you include efficiency of the users, effective management, effective autitability, then pure CPU cycles is a bad metric.

non-repudiation is hopeless. The crypto-net world got completely wrapped around the axis over it in the early 90s. Its a known unsolvable problem.

The problem with non-repudiation and related religions is that it is attempting to use technology to address a human trust conflict. There is no technology that will generate trust.

OK, but you can't use "secure" even in quotes. I'm a bit confused, in one line you say you control/own both ends (which makes this easy) and then you say that one end will be controlled by the attacker, Mallet.

Which is it?

In general, if Mallet has physical access to a trusted computer, it is no longer trusted. This takes you from the easy case (two trusted ends, untrusted communications) to one that is unsolvable.

Also I'm not sure I understand what you mean by


Does this just reinforce that Mallet is sitting at the keyboard? if so, what are you authentifying?

Give the user going out into the field a usb key / smart card with an secret key inside it. Said secret key is encrypted by the user's password and must be entered to gain access to the secret key used for transmission.
That way the user would have to be forced to give out his password before the attacker could impersonate him.

That's the conclusion I'm coming to...

I'm trying to remove the user completely from this...

Best regards,
AstroTux.

I actually like the SecureId or Verisign's equivalent, hardware token that the user looks at and types in a number. Much stronger than a user's password. Not perfect.

On smartcards, see smart cards considered stupid

A usb key with a flashed secret may be a viable secret, but you would have to get a read only one, or Mallet can just enter his key. It would work as a "something you have".

But given that @astro is talking about Mallet being at the keyboard during normal use.

A simple read-only USB key would be subject to replay attacks.

Defending from replay attacks is hard in any case, and with Mallet at the keyboard I'm not sure it can be solved.