September 2015 Archives

Tue Sep 29 12:21:29 EEST 2015

Cheating about pollution appears to be common practice, not only Volkswagen did it

From wikipedia
In 1973, Chrysler, Ford Motor Company, General Motors, Toyota, and Volkswagen had to remove ambient temperature switches which affected emissions, though the companies denied intentional cheating and said that strategies like enriching fuel mixture during cold engine warm-up periods could reduce overall pollution.
In 1996 General Motors had to pay a near-record fine of $11 million, and had to recall almost as many cars as Volkswagen's US TDI diesels, 470,000, when they, like Volkswagen, programmed ECU software to disengage emissions controls during conditions known to exist when the cars were not being lab tested by the EPA.
There are more cases linked.

Posted by pollution | Permanent link

Sun Sep 27 11:42:40 EEST 2015

VW: Just the tip of the pollution iceberg
Volkswagen is being rightly condemned from all directions, as its methods were particularly cynical: its engine software would sense when the car was in a test environment and cut back NOx output temporarily.
As soon as the car was no longer under test, the car would change mode and emit huge amounts of NOx. This wasn't done for no reason – if a machine is allowed to generate NOx freely, it can be very fuel-efficient – and thus, of course, its carbon emissions can be very low too.

Posted by space car | Permanent link

Tue Sep 15 17:07:15 EEST 2015

Just unsubscribed from Fyodor's fucked full disclosure mailing list

Just unsubscribed from Fyodor's fucked full disclosure mailing list

Posted by not Fyodor | Permanent link

Sat Sep 5 10:49:05 EEST 2015

RFC-2631, fips 186-3 and openssl's implementation of DSA appear broken (and possibly backdoored)

The discsussion, certs and keys are at this thread:

1. RFC-2631 Diffie-Hellman Key Agreement Method

The main problem appears:

2.2.2.  Group Parameter Validation
   The ASN.1 for DH keys in [PKIX] includes elements j and validation-
   Parms which MAY be used by recipients of a key to verify that the
   group parameters were correctly generated. Two checks are possible:

     1. Verify that p=qj + 1. This demonstrates that the parameters meet
        the X9.42 parameter criteria.
     2. Verify that when the p,q generation procedure of [FIPS-186]
        Appendix 2 is followed with seed 'seed', that p is found when
        'counter' = pgenCounter.

The main problem appears MAY.

As I read it, implementation MAY NOT verify it.

Sketch of the attack:

Chose $q$ product of small primes $p_i$.

Solve the discrete logarithm in the $p_i$ subgroups for the public keys.

Apply the Chinese remainder theorem to get the privates keys.

2. From the openssl 1.0.1p source: crypto/dsa/dsa_ossl.c:329

   i = BN_num_bits(dsa->q);
    /* fips 186-3 allows only different sizes for q */
    if (i != 160 && i != 224 && i != 256) {
        return -1;

Forcing small subgroups smells to me...

3. openssl 1.0.1p accepts composite $q$ in sign/verify
and over SSL (DSA). The attack in (1) works the same way.


 ./apps/openssl s_server -accept 8080 -cert ./cacert2.pem -key ./key-comp2.key -HTTP

 openssl s_client -connect localhost:8080

 Server public key is 1204 bit
 Verify return code: 18 (self signed certificate)

 sage: q=0x008000000000000000001d8000000000000000012b
 sage: factor(q)
 604462909807314587353111 * 1208925819614629174706189

Posted by jcrank | Permanent link