peculiar ssh stuttering

I've been working on my own ssh implementation for a while now, as
those of you also on the ietf-ssh list may remember.

This would be neither here nor there for this list, except that one of
the machines I've been using for my basic interop testing is a
NetBSD/sparc 2.0 box.  Everything's been fine in the past, but today I
added the aes* modes, and I promptly ran into a very peculiar problem.

The version string from the peer sshd in question is
"SSH-1.99-OpenSSH_3.6.1 NetBSD_Secure_Shell-20030917"; it's a vanilla
2.0 sshd.  When I tell my ssh client to offer only aes128-cbc for
encryption, it goes into a peculiar livelock failure mode.  Key
exchange completes, apparently normally.  Then it goes through the
usual startup mechanisms, which run normally until it comes time to
authenticate.

I see my client sending a USERAUTH_REQUEST packet with a method name of
"publickey", my public key in it, and no signature.  I get back a
USERAUTH_PK_OK packet.  I then compute an authentication signature and
send another USERAUTH_REQUEST, this time containing the signature.
This provokes another PK_OK packet, to which I reply with another
signature-bearing USERAUTH_REQUEST.  These last two packets repeat
until I get fed up and kill the process manually (well, I haven't
waited forever, but I do have traces showing over 25 REQUEST/PK_OK
pairs exchanged).

The bizarre part is that if I use, say, 3des-cbc, or blowfish-cbc,
everything works fine, even against the same running master sshd
process.  Yet obviously my aes128-cbc implementation basically works or
I'd be getting garbaged packets and/or MAC failures instead of
correctly formatted, syntactically reasonable packets that are un-sane
at the conceptual level.  And I don't think it's some weird mistake in
my crypto duplicating input packets, because I see a half-dozen
encrypted packets exchanged without apparent problem before it starts
repeating the REQUEST/PK_OK exchange.

Any ideas what could be happening here?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B