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.
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.
Sun Sep 27 11:42:40 EEST 2015
VW: Just the tip of the pollution iceberg
http://www.theregister.co.uk/2015/09/25/vw_pollution_just_the_tip_of_the_iceberg_whos_to_blame_you_guessed_it_hippies/
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.
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
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:
https://cpunks.org/pipermail/cypherpunks/2015-September/009007.html
1. RFC-2631 Diffie-Hellman Key Agreement Method
https://tools.ietf.org/html/rfc2631
The main problem appears:
https://tools.ietf.org/html/rfc2631#section-2.2.2
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) {
DSAerr(DSA_F_DSA_DO_VERIFY, DSA_R_BAD_Q_VALUE);
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.
Session:
./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