SRP implementation - choices for N and g
Hi list Has anybody already gained experience concerning the technical implementation of SRP (http://srp.stanford.edu)? There is one point I couldn't find in any documentation: Should the modulus and the generator (N and g) be unique for each client or can they be chosen application-wide? What are the (security-related) implications in each case? Thanks, Michael - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [cryptography] 5x speedup for AES using SSE5?
Hovav Shacham wrote:
On Aug 24, 2008, at 5:20 AM, Peter Gutmann wrote:
Speaking of CPU-specific optimisations, I've seen a few algorithm
proposals
from the last few years that assume that an algorithm can be scaled
linearly
in the number of CPU cores, treating a multicore CPU as some kind of
SIMD
engine with all cores operating in lock-step, or at least engaging in
some
kind of rendezvous every couple of cycles (for example the
recently-discussed
MD6 uses a round of 16 steps, if I read the description correctly)
My impressions from Ron's talk were different. For multicore systems,
the tree structure of the hash allows parallelism at a much higher
granularity. For hardware implementation, the feedback-register
structure of the round function means that 16 steps can be computed in
parallel. I didn't get the sense that Ron intends for the second kind
of parallelism to be used in software implementations.
Hovav.
From the MD6 powerpoint, it does look good for parallelism. When using
SSE5 (to get back on topic :-), you should be able to do 2 blocks in the
one instruction stream. I can't remember enough of the other SSE
instructions to know if the relevant 64bit shifts are present before SSE5.
The only place where I've used multiple CPUs in crypto so far has been
in RSA's CRT, where, due to the magic of
OpenMP support, and a little bit of state splitting, I get the following
throughput numbers for dual core 2.5ghz, athlon64
doing 1024-2 RSA private key operations (number per second)
For normal single threaded, 4650 per cpu second and wall clock second.
OpenMP, 4330 per CPU second, 7360 wall clock second.
So in this case, the OpenMP overhead is about 8% CPU. MD6 has smaller
chunks, and lots of them, so it will probably scale quite well.
OpenMP, it makes it very easy to put in parallelism. In this CRT
implementation, it was a simple
#pragma omp parallel for
for (i=0; i2; i++)
/* CRT code */
A few changes were made to make sure the structures were not shared, but
nothing that affects performance.
OpenMP is now in gcc 4.2 which is nice.
MD6, should be just as stupidly easy,
#pragma omp parallel for
for (block_num=0; block_num(data_len/512); block_num++) {
MD6_block((ret_st[block_num]), input + block_num*512, block_num,
level, not_root, )
}
Repeat up the levels (depending of memory availability).
eric
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
road toll transponder hacked
Drivers using the automated FasTrak toll system on roads and bridges in California's Bay Area could be vulnerable to fraud, according to a computer security firm in Oakland, CA. Despite previous reassurances about the security of the system, Nate Lawson of Root Labs claims that the unique identity numbers used to identify the FasTrak wireless transponders carried in cars can be copied or overwritten with relative ease. http://www.technologyreview.com/Infotech/21301/?a=f -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 5x speedup for AES using SSE5?
Brian Gladman wrote: But a fully byte oriented implementation runs at about 140 cycles/byte and here the S-Box substitution step is a significant bottleneck. ... It is also possible that the PPERM instruction could be used to speed up the Galois field calculations to produce the S-Box mathematically rather than by table lookup. I have tried this in the past but it has not proved competitive. But PPERM looks interesting here as well. This is where the following may be handy: http://www.literatecode.com/2007/11/11/aes256/ It is a byte-oriented AES-256 implementation without S-box tables. Although I doubt it can be speeded up that much. Regards, Ilya -- http://www.literatecode.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SRP implementation - choices for N and g
Michael Tschannen wrote: Has anybody already gained experience concerning the technical implementation of SRP (http://srp.stanford.edu)? There is one point I couldn't find in any documentation: Should the modulus and the generator (N and g) be unique for each client or can they be chosen application-wide? What are the (security-related) implications in each case? They can safely be chosen application-wide, so long as they are secure choices as per the Group parameter agreement section of the SRP spec. -- __ \/ o\ Paul Crowley, [EMAIL PROTECTED] /\__/ http://www.ciphergoth.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: road toll transponder hacked
On Tue, Aug 26, 2008 at 9:24 AM, Perry E. Metzger [EMAIL PROTECTED] wrote: http://www.technologyreview.com/Infotech/21301/?a=f From the article: other toll systems, like E-Z Pass and I-Pass, need to be looked at too A couple years ago I got a letter from E-Z Pass a few days after I used my transponder in my new car without registering my new car. They gave me a grace period to register before making me pay some sort of penalty. So, I believe, at least for E-Z Pass, the attack would have to include cloning the license plate and pictures may still be available whenever a victim realizes they have been charged for trips they did not take. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
On Tue, Aug 26, 2008 at 9:24 AM, Perry E. Metzger [EMAIL PROTECTED] wrote: Despite previous reassurances about the security of the system, Nate Lawson of Root Labs claims that the unique identity numbers used to identify the FasTrak wireless transponders carried in cars can be copied or overwritten with relative ease. Nate hasn't disclosed details of the code that wirelessly overwrites a transponder's ID. The temptation would be too great for many to copy an annoying neighbour's transponder ID, and then drive through a busy mall parking lot cloning it onto every transponder in proximity. As mentioned in the article, the vendors have claimed it was read-only, even though it uses flash memory (I guess technically they could cut the write line in manufacturing, but realistically that was highly unlikely even before Nate did this work). I would speculate that they just looked at the high level design, which didn't contain any specifications for features to write to memory, and decided that meant 'read-only'. In the meantime, the implementers don't see any harm in adding a few extra features *beyond* what is in the design (viz.: the overwrite code) especially where that might be useful for testing and diagnostics. As an aside: Isn't it noteworthy how much less press this has gotten than the Boston subway hacks, even though it is (IMO) of much greater severity? There might be a lesson there for the Massachussetts Bay Transit Authority. Ken - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
yet more NSA tech journal articles declassified...
Hat tip: John Young's Cryptome... http://www.nsa.gov/public/tech_journals.cfm -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
On Aug 26, 2008, at 10:15, [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 9:24 AM, Perry E. Metzger [EMAIL PROTECTED] wrote: http://www.technologyreview.com/Infotech/21301/?a=f From the article: other toll systems, like E-Z Pass and I-Pass, need to be looked at too A couple years ago I got a letter from E-Z Pass a few days after I used my transponder in my new car without registering my new car. They gave me a grace period to register before making me pay some sort of penalty. So, I believe, at least for E-Z Pass, the attack would have to include cloning the license plate and pictures may still be available whenever a victim realizes they have been charged for trips they did not take. I believe that's correct. In fact, the plate recognition technology they use seems to be good enough to make the transponder itself redundant. I know several people with E-Z Pass who disconnected the internal battery of their transponder (out of concern that there might be hidden readers around town that track vehicles at places other than toll gates). Even with dead transponders, their accounts are still charged accurately when they pass toll gates. (The sign displays EZ Pass not read or some such thing, but the account is debited within a day or two anyway). -matt - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
On Tue, 2008-08-26 at 10:52 -0400, Matt Blaze wrote: On Aug 26, 2008, at 10:15, [EMAIL PROTECTED] wrote: So, I believe, at least for E-Z Pass, the attack would have to include cloning the license plate and pictures may still be available whenever a victim realizes they have been charged for trips they did not take. I believe that's correct. In fact, the plate recognition technology they use seems to be good enough to make the transponder itself redundant. I know several people with E-Z Pass who disconnected the internal battery of their transponder (out of concern that there might be hidden readers around town that track vehicles at places other than toll gates). Even with dead transponders, their accounts are still charged accurately when they pass toll gates. (The sign displays EZ Pass not read or some such thing, but the account is debited within a day or two anyway). This is the same for the state-wide Texas tag, TxTag[1]. If your tag doesn't register, or you disable or remove it, the toll system can still accurately bill you based on your license plate and vehicle registration. If you're not in the TxTag system at all, they simply mail you a bill. [1] http://www.txtag.org/ -- Dustin D. Trammell Security Researcher BreakingPoint Systems, Inc. signature.asc Description: This is a digitally signed message part
Re: road toll transponder hacked
On Tue, Aug 26, 2008 at 11:56 AM, Dustin D. Trammell [EMAIL PROTECTED] wrote: This is the same for the state-wide Texas tag, TxTag[1]. If your tag doesn't register, or you disable or remove it, the toll system can still accurately bill you based on your license plate and vehicle registration. If you're not in the TxTag system at all, they simply mail you a bill. I think this is a bit different than what Michael Heyman said. TxTag, IIRC, was implemented by the same company (Raytheon) that implemented the 407 ETR toll system in Toronto. In the case of the 407, there is no image recognition done if the car has a valid transponder. Only in the case of a missing or invalid transponder is the plate imagery used. Supposedly the OCR has a high enough error rate that there is still manual verification of plates before sending a bill, and accordingly a $3.60 additional charge is applied per trip. If the images are used even when the vehicle has a valid transponder -- as Michael Heyman suggests is happening with E-ZPass -- then it might be feasible to have back end defenses against cloning, though not without inconvenience to customers who borrow cars, buy new cars, or rent cars while their own is getting serviced. Also as Matt Blaze pointed out this makes the transponder wholly redundant. Ken - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
So, I believe, at least for E-Z Pass, the attack would have to include cloning the license plate and pictures may still be available whenever a victim realizes they have been charged for trips they did not take. The 407 toll road in Toronto uses entirely automated toll collection. They offer transponders (which, annoyingly, are the same system as NY's EZ-Pass but don't interoperate) for commuters and trucks, but for casual use by cars, it reads your plates and sends you a bill. I can report from experience that when I use it with my NY plates, I always get a bill a month or so later. R's, John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
On Tue, 2008-08-26 at 13:22 -0400, Ken Buchanan wrote: On Tue, Aug 26, 2008 at 11:56 AM, Dustin D. Trammell [EMAIL PROTECTED] wrote: This is the same for the state-wide Texas tag, TxTag[1]. If your tag doesn't register, or you disable or remove it, the toll system can still accurately bill you based on your license plate and vehicle registration. If you're not in the TxTag system at all, they simply mail you a bill. I think this is a bit different than what Michael Heyman said. TxTag, IIRC, was implemented by the same company (Raytheon) that implemented the 407 ETR toll system in Toronto. In the case of the 407, there is no image recognition done if the car has a valid transponder. Only in the case of a missing or invalid transponder is the plate imagery used. Supposedly the OCR has a high enough error rate that there is still manual verification of plates before sending a bill, and accordingly a $3.60 additional charge is applied per trip. If the images are used even when the vehicle has a valid transponder -- as Michael Heyman suggests is happening with E-ZPass -- then it might be feasible to have back end defenses against cloning, though not without inconvenience to customers who borrow cars, buy new cars, or rent cars while their own is getting serviced. Also as Matt Blaze pointed out this makes the transponder wholly redundant. I can confirm that they definitely use imagery even when a valid transponder is detected. A couple years or so ago I had to put my vehicle in the shop and use the wife's for a few days. I assumed that I could use my TxTag in her vehicle, and it would simply bill my account, however a couple of weeks later I received a bill for the tolls, billed to the owner of her vehicle at our address. When I called to inquire, they informed me that it did read the transponder, but mismatched with the plates. There was a grace period during which I could update the transponder to the new vehicle and avoid the fines, but as I would be getting my vehicle back in a few days, I opted to just order a second transponder for her car. They were kind enough to transfer the tolls to the new transponder and waive the fees. -- Dustin D. Trammell Security Researcher BreakingPoint Systems, Inc. signature.asc Description: This is a digitally signed message part
Re: road toll transponder hacked
[EMAIL PROTECTED] (Ken Buchanan) on Tuesday, August 26, 2008 wrote: I think this is a bit different than what Michael Heyman said. TxTag, IIRC, was implemented by the same company (Raytheon) that implemented the 407 ETR toll system in Toronto. In the case of the 407, there is no image recognition done if the car has a valid transponder. Only in the case of a missing or invalid transponder is the plate imagery used. Supposedly the OCR has a high enough error rate that there is still manual verification of plates before sending a bill, and accordingly a $3.60 additional charge is applied per trip. If the images are used even when the vehicle has a valid transponder -- as Michael Heyman suggests is happening with E-ZPass -- then it might be feasible to have back end defenses against cloning, though not without inconvenience to customers who borrow cars, buy new cars, or rent cars while their own is getting serviced. Also as Matt Blaze pointed out this makes the transponder wholly redundant. I could see where knowing what the license plate should be, from the transponder code, could feed back into the OCR and only generate a hit when the disagreement was obvious. In the San Francisco Bay Area, they are using the transponder codes to measure how fast traffic is moving from place to place. They post the times to various destinations on the electric signs when there are no Amber alerts or other more important things to display. It is quite convenient, and they promise they don't use it to track people's trips. If one were paranoid, one could put a different ID into the transponder for each trip, and only put the one it was issued with into it for toll crossings. :-) Cheers - Bill --- Bill Frantz|We used to quip that password is the most common 408-356-8506 | password. Now it's 'password1.' Who said users haven't www.periwinkle.com | learned anything about security? -- Bruce Schneier - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
OpenSSH compromise at Red Hat
I'm a bit surprised no one has mentioned the Red Hat server being hacked and the certificated being compromised on Fedora. http://www.eweek.com/c/a/Security/Red-Hat-Digital-Keys-Violated-By-Intruder/ Best, Allen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
