Re: Client Certificate UI for Chrome?
James A. Donald jam...@echeque.com writes: [Incredibly complicated description of web scripting plumbing deleted] Peter Gutmann wrote: We seem to be talking about competely different things here. For a typical application, say online banking, I connect to my bank at www.bank.com or whatever, the browser requests my credential information, and the TLS-SRP or TLS-PSK channel is established. That's all. There's no web application framework and PHP and scripting and other stuff at all, in fact I can't even see how you'd inject this into the process. I cannot see how you could create a bank web page without a web application framework (counting mod-php as a very primitive web application framework) and scripting and a database, which scripting and database has to know who it is is that logged in - which is indeed a great deal of complicated plumbing to ensure that the script knows at script execution time, *after* the connection has been made, which user, which database primary key, is connected. The information about which user, which database primary key is logged in, has to be passed up through one layer after another and from one process to another. The toe bone is connected to foot bone, the foot bone is connected to the ankle bone, the ankle bone is connected ... The plumbing really is that complicated. Further, if we do the SRP dance every single page, it is a huge performance hit, with many additional round trips. One loses about 20 percent of one's market share for each additional round trip. You only do it once when the TLS session is set up, it's exactly as for standard TLS except that instead of PKI-based non-authentication you use cryptographic mutual authentication. How do you get an SRP exchange for every web page? Because keep-alive usually fails for plumbing reasons, standard TLS usually does the PKI-based non-authentication dance every page, resulting in additional round trips, resulting in painfully bad performance for SSL web sites such as https://www.cia.gov/library/publications/the-world-factbook/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
512 bit RSA key used for TI 83+ auth cracked
It seems the TI-83+ operating system is protected using some form of code signing scheme using a 512 bit RSA key. That key has now been factored: http://www.unitedti.org/index.php?showtopic= Which apparently will allow custom operating systems to run on the device. While this certainly is not the first 512 bit RSA moduli to be factored, this may be the first one that was performed (publicly, at least) with the goal of breaking an existing system, rather than simply demostrating progress in algorithms and hardware. Interestingly, it was reportedly done with only a single machine, over the course of 73 days. Details on the computation are lower down in the thread: How did I do this? With the best tools I could find for the job. The best algorithm for factoring really large general numbers (i.e., numbers without any special properties) is the general number field sieve. The best currently-available implementation of the GNFS consists of a combination of the GGNFS and Msieve projects. It's really the guys behind these tools who deserve the credit for making this possible. While it does take a bit of work to get the tools set up correctly, most of what I did was sitting around waiting for it to finish, and every once in a while, telling the script to try another filtering run. smile.gif Some fun statistics: - The factorization took, in total, about 1745 hours, or a bit less than 73 days, of computation. (I've actually been working on this since early March; I had a couple of false starts and haven't been able to run the software continously.) - My CPU, for reference, is a dual-core Athlon64 at 1900 MHz. - The sieving database was 4.9 gigabytes and contained just over 51 million relations. - During the filtering phase, Msieve was using about 2.5 gigabytes of RAM. - The final processing involved finding the null space of a 5.4 million x 5.4 million matrix. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
2 serving time in UK prisons for refusing to decrypt on demand
[But we don't know who they are! --gnu] http://www.theregister.co.uk/2009/08/11/ripa_iii_figures/ Two convicted for refusal to decrypt data Up to five years in jail after landmark prosecutions By Chris Williams Posted in Policing, 11th August 2009 13:17 GMT Two people have been successfully prosecuted for refusing to provide authorities with their encryption keys, resulting in landmark convictions that may have carried jail sentences of up to five years. The government said today it does not know their fate. The power to force people to unscramble their data was granted to authorities in October 2007. Between 1 April, 2008 and 31 March this year the first two convictions were obtained. The disclosure was made by Sir Christopher Rose, the government's Chief Surveillance Commissioner, in his recent annual report. The former High Court judge did not provide details of the crimes being investigated in the case of either individual - neither of whom were necessarily suspects - nor of the sentences they received. The Crown Prosecution Service said it was unable to track down information on the legal milestones without the defendants' names. Failure to comply with a section 49 notice carries a sentence of up to two years jail plus fines. Failure to comply during a national security investigation carries up to five years jail. Sir Christopher reported that all of the 15 section 49 notices served over the year - including the two that resulted in convictions - were in counter terrorism, child indecency and domestic extremism cases. The Register has established that the woman served with the first section 49 notice, as part of an animal rights extremism investigation, was not one of those convicted for failing to comply. She was later convicted and jailed on blackmail charges. Of the 15 individuals served, 11 did not comply with the notices. Of the 11, seven were charged and two convicted. Sir Christopher did not report whether prosecutions failed or are pending against the five charged but not convicted in the period covered by his report. To obtain a section 49 notice, police forces must first apply to the National Technical Assistance Centre (NTAC). Although its web presence suggests NTAC is part of the Home Office's Office of Security and Counter Terrorism, it is in fact located at the government's secretive Cheltenham code breaking centre, GCHQ. GCHQ didn't immediately respond to a request for further information on the convictions. The Home Office said NTAC does not know the outcomes of the notices it approves. NTAC approved a total of 26 applications for a section 49 notice during the period covered by the Chief Surveillance Commissioner's report, which does not say if any applications were refused. The judicial permission necessary to serve the notices was then sought in 17 cases. Judges did not refuse permission in any case. One police force obtained and served a section 49 notice without NTAC approval while acting on incorrect information from the Police National Legal Database, according to Sir Christopher. The action was dropped before it reached court. Readers with further information about the convictions can contact the reporter in confidence here. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
James A. Donald jam...@echeque.com writes: I cannot see how you could create a bank web page without a web application framework (counting mod-php as a very primitive web application framework) and scripting and a database, which scripting and database has to know who it is is that logged in We really are talking about completely different things here. The scripting and whatnot has nothing to do with TLS or TLS auth mechanisms. The only thing you need to care about (if you really want to go this way) is channel binding. The information about which user, which database primary key is logged in, has to be passed up through one layer after another and from one process to another. Yeah, and that's what channel binding is for. The plumbing really is that complicated. Only if you deliberately choose to make it so. Read the RFCs I mentioned earlier. Because keep-alive usually fails for plumbing reasons, standard TLS usually does the PKI-based non-authentication dance every page, resulting in additional round trips, resulting in painfully bad performance for SSL web sites But TLS doesn't work like that. If it did, you'd get a cert popup every time you clicked on a link on a TLS-protected web site. Unless you somehow manage to flush the TLS session cache on the server (which seems unlikely unless you're DoS'ing it) there's no additional round-trip(s), or additional anything for that matter. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto'09 Rump session to be webcast
This year's rump session will include A Live Trojan Message for MD5 A New Security Analysis of AES-128 In how many ways can you break Rijndael? Alice and Bob Go to Heaven The full agenda has been posted at http://rump2009.cr.yp.to/ On Aug 14, 2009, at 11:56 AM, james hughes wrote: The first Crypto rump session took place in 1981 and was immediately heralded as the most important meeting in cryptography. Each subsequent Crypto rump session has reached a new level of historical significance, outstripped only by the Crypto rump sessions that followed it. The Crypto2009[1] Rump Session[2] will be broadcast live[3] starting at Tuesday, August 18th at 7:30pm to 11pm (PST/UTC-7)[4]. Download calendar event (ics)[5] [1] http://www.iacr.org/conferences/crypto2009/ [2] http://rump2009.cr.yp.to/ [3] http://qtss.id.ucsb.edu/crypto2009/rump.sdp [4] http://timeanddate.com/worldclock/fixedtime.html?month=8day=18year=2009hour=19min=30sec=0p1=137 [5] http://www.iacr.org/conferences/crypto2009/Crypto2009RumpSessionWe.ics - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
