Corrupted MAC on input

Deron Meranda dmeranda at iac.net
Tue May 4 10:55:24 EST 2004


Darren Tucker wrote:
 > OpenSSL will automatically build [pa-risc2.o] when configured
 > with the HP ANSI C compiler, right?

Yes it will...as long as you stick with 32-bit mode.  You also
used to also have to use static libraries only, but the more
recent sources (as of 0.9.7b) now allow the *.o to be PIC, so
you can use in shared libraries too.


 > the bignum stuff isn't used during the the session unless
 > it gets rekeyed...

 From what I've discovered the bignum stuff (in particular the
hand-coded assembly routines) are only used in any significant
way when performing RSA encryption and when generating Diffie-
Hellman keypairs.  So yes, for SSH that would either occur
during the initial session setup, or during rekeying.

I only use RSA keys with ssh.  I don't use DSA at all.  I also
only use key-based authentication, never password.  I don't think
that matters once you're in.

And I can tell you that from a year ago when I was seriously
trying to debug this problem, I did verify that session rekeying
was not involved in any way with the corrupted MACs occurances.
That was actually one of the first things I checked because it
seemed so obvious.

> Do any of the others [Apache, etc.] use hmac-md5?

Probably not, I think most things negotiate hmac-sha1.


Before I try changing a bunch of settings and stuff, I need to
try to see if I can more predictably trigger this error.

Note that I am going through a Linksys router.  It is a BEFSR41
firmware "1.44.2, Dec 13 2002".  I may try to upgrade it.  I'm
also going through a pair of Linux iptables-based firewalls
near the server side, one of which is NATing.  I have no idea
what other network labyrinths lie between.  It certainly could
be a network/hardware issue.  But what could cause a MAC error,
while surviving the TCP checksum?


Also, another observation, aside from using HP-UX on the server,
I have only witnessed this problem when using an Athlon-based
PC for the client (an older 800 MHz Slot-A model).  But it is
multi-OS, and I've seen the MAC error under both Windows 98SE
(with PuTTY), as well as under Linux using OpenSSH client.  I
wonder if there may be an Athlon client-side issue?

More datapoints would certainly help.  Who else has seen these
MAC errors?


If I can figure out a way to reliably make these occur perhaps I
can provide much more solid input rather than the wild guesses
I seem to be making now.

Deron Meranda




More information about the openssh-unix-dev mailing list