Re: outlook certs - solved

[Eric Young]

 Matt Thomlinson wrote:
 I now believe you've decoded the below incorrectly because the leading bit
 is set, making this a signed number which may have made some of your tools
 croak. Decoding by hand, I get the following mod/exp:
 
 3047 0240  (asn, len, int tag, length of 40)
 
 modulus:
 DFAA A0F4 0CA3 853E 6942 C98D AC3F 1257 4ADB 50CB 263F 99E0 A922 1166 CD1E
 959C 34EF BC66 84DF E3F7 3C62 F6B0 7D20 FE89 3B52 846F DD21 E099 C187 A1E3
 FE1B 14C3
 
 
 0203 (int tag, length of 3)
 exponent:
 0100 01

It is definitely a bug in the ASN.1 encoding of the certificate.
ASN.1 has definite rules about how to encode/decode INTEGERs.

# Print the contents of the certificates public key
ssleay asn1parse -offset 186 -length 73 cert.pem
0:d=0  hl=2 l=  71 cons: SEQUENCE  
2:d=1  hl=2 l=  64 prim: INTEGER   :-2156600CF45D7BC297BE377354
C1EEA9B625B035DAC1672057DEEF9A33E26B64CC11449A7C211D09C49E0A5083E00277C5AE7
C9123DF20673F795F1D02E5EC3D
   68:d=1  hl=2 l=   3 prim: INTEGER   :010001

The problem is that the ASN_INTEGER is encoded as
02 BER_INTEGER
40 length 0x40
DF first byte   (if top bit is set, the number is negative)
AA second byte
This means that the modulus has been encoded as a negative ASN1_INTEGER,
(the 0x80 bit is set in the first byte).  There should be a leading 0x00.
ASN.1 negative numbers are stored in twos complement form.  The
SSLeay/OpenSSL X509 printing tool is not displaying the 'negative' sign,
but the conversion from -ve twos complement to the internal libraries
bignum representation is occurring (negatives converted to '+ve' and
a flag is used to store the sign).

The other place where this shows up quite often is in the form of -ve serial
numbers on the certificates.

Another one for Peter Gutmann's collection of miss implemented ASN.1.

eric

Re: SSLeay.Org Still A Trusted Source?

[Eric Young]

"Salz, Rich" wrote:
 
 SSLeay is dead, long live OpenSSL.
 The domain is now owned by a squatter.
 C'est la vie.
 /r$

Just as an update, I'm looking into seeing if I can do about this.
I feel it should point to a 'historical' SSLeay page if nothing else.

eric (who has just lodged last years tax return, only 10 month late...).
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] (which is why SSLeay is not being developed)

Re: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet

[Eric Young]

John Gilmore wrote:
 raw data rate, since 10-20% is used by packet headers/trailers/interpacket
 spacing/etc.  And I've never seen software 3DES run at 32 Mbits/sec;
 what processor were they using?

On a pentium II 350, I get triple DES in cbc-ede mode doing 23.2
Mbits/sec
(Mbits == 1e6).  The DES cbc mode numbers are 65 Mbits/sec.

So doing the simple maths, I get a 482 mhz, or I'd say a pentium 2/3
500.

eric

Re: Clear Session ID in SSLV3

[Eric Young]

"Marcus J. Ranum" wrote:
 
 Does anyone have a pointer to why the session ID in SSLV3 is
 in the clear, rather than encrypted? I'm sure there's a good
 reason for it (audit? logging? other...?)  but I'm trying to
 pin down exactly why it was done that way. Can anyone point
 me in the right direction?

Because it is sent in the first message from the client
to the server.  It is intended to short circuit the
SSL protocol handshake and reduce the number of messages
exchanged.

Since the client and server don't have a known shared secret yet,
we cannot encrypt the session-id.

eric