Thursday Nov 15, 2007

Poaching codepoints

I'm in the midst of building our own flavor of labelled IPsec for Trusted Extensions, and took a look at what the "competition" (specifically, SELinux) is doing.  I was surprised to notice that (at least if the ipsec-tools-0.7 source is to be believed) they've grabbed a codepoint assigned to RFC 3168 (Explicit Congestion Negotiation) rather than actually asking for one to be assigned via the normal IANA processes, or using the long-defined but rarely used capabilities of ikev1 to carry a sensitivity label. 

It looks like racoon2 gets this right (but doesn't have the SElinux security context support).

I can't be the first person to notice this, can I?

Tuesday Oct 18, 2005

Creative Hash Functions

Take a quick look at this macro definition.   Did you spot the bug?

Because of poor paren placement, the OUTBOUND_HASH_V6 macro in sadb.h
computes a hash value of:
        \*x\^(\*x+1)\^(\*x+2)\^(\*x+3)
when:
        x[0]\^x[1]\^x[2]\^x[3]
was intended, with the result that only a small number of outbound hash buckets are ever used.  Half end up in bucket 0.  All hash values have two low order bits of zero, then (going upwards) zero or more 1 bits, and then all zeros until the top of the word.  Distribution looks like:

value:         occurances
       0         2147483648
       4         1073741824
       c          536870912
      1c          268435456
...
1ffffffc                 16
3ffffffc                  8
7ffffffc                  4
fffffffc                  4

needless to say, this distribution is awful, with only 31 unique hash values, and with 50% of entries in one bucket, and with 99% of hits in only 7 buckets. 

Discovered this shortly before 10:30 this morning; filed bug 6338289; tested fix on x86 and sparc, code reviewed, and integrated into the development sources by 5:50pm this afternoon. 

UPDATE: In response to a comment: Yes, inline functions would be better here, but the compiler version we used during solaris 9 development didn't support them in C.    If we're going to revisit this code, a more likely mini-project here is to find all the various places within IP where we compute hash functions based on a protocol address, find the best one, and make that a common one used by all the address-based hash functions, possibly tossing in a key or equivalent as a defense against hash-bucket-clogging attacks.

Thursday May 12, 2005

Old News (encryption without integrity protection may not yield confidentiality)

As one of Sun's IPsec developers, I've been getting queries regarding a recent advisory from a UK agency regarding common mistakes made when configuring IPsec-based VPN tunnels.  This advisory has gotten some press coverage, but isn't really news. 

I first heard about it from Steve Bellovin at the IETF meeting in Danvers, Massachusetts over 10 years ago; he subsequently published "Problem Areas for the IP Security Protocols" describing this flaw.

And, if you try to set this up using Solaris's IPsec, you get warned:

# ifconfig ip.tun0 plumb encr_algs aes
ifconfig: WARNING - tunnel with only ESP and potentially no authentication.


I hope other vendors will add similar warnings now..

Tuesday Aug 17, 2004

Hash crash

Interesting times for cryptographic hash functions..

On Perry Metzger's Cryptography mailing list, we find first a report of a collision found in the original (never widely used) SHA function, and then the bigger report that four researchers in China have apparently come up with a general method for attacking MD4-like hash functions. Most impressively, they say about MD4:

Our attack can find collision with hand calculation.

There are also rumors of an impending announcment of a collision in SHA-1. No word yet on whether/how these methods can be extended to SHA-256/384/512; it looks doubtful that they'll be useful against HMAC-based constructions but other uses of hash functions need closer examination.

The attacks find pairs of messages which hash to the same value -- but nobody has yet revealed the algorithms in use; this is likely a much easier problem than finding a message which hashes to a fixed value. The MD4/MD5 message pairs differ only in a few bits, while the SHA1 pairs (produced by a different research group) differ by quite a bit more -- this is likely an artifact of the more complex message schedule found in the SHA series. SHA-256 and up use an even more complex message schedule.

About

sommerfeld

Search

Top Tags
Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today