Hay Chris, all
1234567890123456789012345678901234567890123456789012345678901234567890123456
7890
> I definitely agree that it's important to make this stuff work
> on smaller systems.  But...


> Is MD5 really that much faster than SHA1? (MD5 has known problems
> and there are RFC's saying not to use it)

Yes, MD5 for hashing should be at least twice as fast. However hashing isn't
the bottleneck

A colleague, which is much more a crypto-export then I'm, will give me some
figures to compare. I'm waiting on them.

But, his first suggestions, as alternatives to SHA1/DSA are:
  1) SHA1 with RSA              RSA is a lot faster then DSA
  2) MD5  with RSA              MD5 & RSA are faster:  quite fast
  3) DES in CBC mode            very fast
         This (3) gives a MAC not a signature (see note 1)

Alternative 3 should be the fastest one. Alternative 1 is faster then
SHA1/DSA, but hardly used because alt-2 is better (faster) at no cost.

I don't have them implemented yet, so I don't have figures about them. Hope
to do some measurements next week.


> As for asymmetric keys, there are several problems:

I assume you mean symmetric (as DES is) ...

> 2.  Can't show as easily in court that a particular device
>      generated the  logs.

It's even impossible! It doesn't give a signature, but a MAC; see below
(note 1)

> 3.  Messages subject to known plaintext attacks similar to
>     the attacks  on WEP.

Not quite. The problems with WEP are not due to the algorithm (witch is MD5
it think), but a "bug" in the design.


And remember, even if method XYZ less then optimal. It will add (some)
security. Some environments will require the best one's Some not, the need
an affordable one. Compare it to normal keys: The key on the front and
backdoor are strong. The key for my bedroom is simple and cheep! It will not
stop a burglar, it will stop interruptions on "wrong moments" :-)

Note 1 MAC versus signatures
=======
As I understand, it's isn't possible to generate a signature with a
symmetric algorithm as DES. You can however generate a MAC:
Message Authentication Code. With it, you can prove the message isn't
changed. (but you need the "private" (only) key for it).
You can not use a MAC to prove who send it. But when you can keep your
key(s) out of "wrong hands" And you can verify each has the correct MAC,
some security is added!

Note 2 syslog-sign and security
==========
We have to keep in mind syslog-sign does only add some security. No
encryption of messages is done, anybody can read all messages. There are no
means to prevent somebody can insert (or at least send) fake messages. etc
All syslog-sign does is send some "extra data", which makes it possible to
detect thinks that are wrong! Like fake messages.
Whenever a environment does use syslog-sign, that bit of security will do
(or the will use syslog-reliable).
Which means, the crypto algorithm that are allowed, have to be (more or
less) good at signing. Not more, not less.
A crypto systems which is broken for "encrypted text" isn't a problem. As we
send cleantext only!
It should be hard to fake signatures, that's all!


But as always, it only my opinion.

--ALbert
sent mail to [EMAIL PROTECTED], to address me personal.
sent mail to [EMAIL PROTECTED], to address me for businesses


Reply via email to