Re: A Fault Attack Construction Based On Rijmen's Chosen-Text Relations Attack
Alfonso De Gregorio wrote: The last Thursday, Vincent Rijmen announced a new clever attack on AES (and KASUMI) in a report posted to the Cryptology ePrint Archive: Practical-Titled Attack on AES-128 Using Chosen-Text Relations, http://eprint.iacr.org/2010/337 Jonathan Katz wrote: Err...I read that paper by Rijmen as a bit of a joke. I think he was poking fun at some of these unrealistic attack models. Alfonso De Gregorio wrote: Now, I expect the unusual nature of the attack model might stir up a lively discussion. My post was soliciting comments in this regard. For what it's worth, I read Vincent Rijmen's paper in the same way as Jonathan Katz. I don't think it's intended to be taken at face value; if you took it seriously, one of us needs to read it again. Rather, I saw it as written with tongue embedded firmly in cheek: I took it as a serious argument, hidden behind some gentle humor. Vincent Rijmen could have written a sober, systematic critique of the direction some of the field has gone in, carefully explaining in great detail why some recent attack models are unrealistic. That would have been the safe, standard, and somewhat boring way to present such an argument. But instead Rijmen wrote a one-page lighthearted piece that implicitly makes its point -- without ever having to come out and say it -- by taking this research direction to its absurd extreme and showing us all where it leads to. It follows in a long intellectual tradition of saying the opposite of what you mean -- of arguing with a straight face what is self-evidently a ridiculous position -- and trusting in the intelligence of the reader to draw the obvious conclusions. Personally, I found it an effective communication style. I thought the point came across very clearly. And, I have to admit I enjoyed seeing someone having a spot of fun with what can otherwise be a somewhat dry topic. I thought it was brilliantly done. Sorry to be unable to provide any lively discussion. I think Vincent Rijmen's paper makes the point well, and I don't have anything to add. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
[gd...@microsoft.com: [fc-announce] Call for papers: Financial Cryptography and Data Security (FC2011)]
--- Start of forwarded message --- From: George Danezis gd...@microsoft.com To: fc-annou...@ifca.ai fc-annou...@ifca.ai Date: Wed, 21 Jul 2010 15:56:36 + Subject: [fc-announce] Call for papers: Financial Cryptography and Data Security (FC2011) Financial Cryptography and Data Security (FC 2011), Bay Gardens Beach Resort, St. Lucia February 28 - March 4, 2011 - http://ifca.ai/fc11/ [CFP in PDF: http://ifca.ai/fc11/fc11cfp.pdf] Financial Cryptography and Data Security is a major international forum for research, advanced development, education, exploration, and debate regarding information assurance, with a specific focus on commercial contexts. The conference covers all aspects of securing transactions and systems. Original works focusing on both fundamental and applied real-world deployments on all aspects surrounding commerce security are solicited. Submissions need not be exclusively concerned with cryptography. Systems security and inter-disciplinary efforts are particularly encouraged. Topics include: Anonymity and Privacy, Auctions and Audits, Authentication and Identification, Backup Authentication, Biometrics, Certification and Authorization, Cloud Computing Security, Commercial Cryptographic Applications, Transactions and Contracts, Data Outsourcing Security, Digital Cash and Payment Systems, Digital Incentive and Loyalty Systems, Digital Rights Management, Fraud Detection, Game Theoretic Approaches to Security, Identity Theft, Spam, Phishing and Social Engineering, Infrastructure Design, Legal and Regulatory Issues, Management and Operations, Microfinance and Micropayments, Mobile Internet Device Security, Monitoring, Reputation Systems, RFID-Based and Contactless Payment Systems, Risk Assessment and Management, Secure Banking and Financial Web Services, Securing Emerging Computational Paradigms, Security and Risk Perceptions and Judgments, Security Economics, Smartcards, Secure Tokens and Hardware, Trust Management, Underground-Market Economics, Usability, Virtual Economies, Voting Systems IMPORTANT DATES Workshop Proposal Submission: August 6, 2010 Workshop Proposal Notification: August 30, 2010 Paper Submission: October 1, 2010 Paper Notification: November 15, 2010 Final Papers: December 17, 2010 Poster and Panel Submission: December 3, 2010 Poster and Panel Notification: December 13, 2010 SUBMISSION Submission categories: (i) regular papers (15 pg LNCS format), (ii) short papers (8 pg), (iii) panels and workshops (2 pg), and (iv) posters (1 pg). Anonymized submissions will be double-blind reviewed. Papers must be formatted in standard LNCS format and submitted as PDF files. Submissions in other formats will be rejected. All papers must be submitted electronically according to the instructions and forms found on this web site and at the submission site. Authors may only submit work that does not substantially overlap with work that is currently submitted or has been accepted for publication to a conference with proceedings or a journal. We consider double submission serious research fraud and will treat it as such. In case of doubt contact the program chair for any clarifications at fc11ch...@ifca.ai. Regular Research Papers. Research papers should describe novel, previously unpublished scientific contributions to the field, and they will be subject to rigorous peer review. Accepted submissions will be included in the conference proceedings to be published in the Springer-Verlag Lecture Notes in Computer Science (LNCS) series. Submissions are limited to 15 pages. Short Papers. Short papers are also subject to peer review, however, the intention is to encourage authors to introduce work in progress, novel applications and corporate/industrial experiences. Short papers will be evaluated with a focus on novelty and potential for sparking participants' interest and future research avenues. Short paper submissions are limited to 8 pages in standard LNCS format. The paper title for short papers should necessarily include the text '(a short paper)'. Panel Proposals. We especially would like to encourage submissions of panel proposals. These should include a very brief description of the panel topics, as well as of the prospective panelists. Accepted panel sessions will be presented at the conference. Moreover, each participant will contribute a one-page abstract to be published in the conference proceedings. Please feel free to contact us directly if you would like to further discuss the suitability of a certain topic. Panel submissions should be up to 2 pages, sent to fc11ch...@ifca.ai. Posters. The poster session is the perfect venue to share a provocative opinion, interesting established or preliminary work, or a cool idea that will spark discussion. Poster presenters will benefit from a multi-hour session to discuss their work, get exposure, and receive feedback from attendees. Poster submissions should be 1 page (in the same LNCS format). Please keep in mind
A mighty fortress is our PKI
Readers are cordially invited to go to https://edgecastcdn.net and have a look
at the subjectAltName extension in the certificate that it presents. An
extract is shown at the end of this message, this is just one example of many
like it. I'm not picking on Edgecast specifically, I just used this one
because it's the most Sybilly certificate I've ever seen. You'll find that
this one Sybil certificate, among its hundred-and-seven hostnames, includes
everything from Mozilla, Experian, the French postal service, TRUSTe, and the
Information Systems Audit and Control Association (ISACA), through to
Chainlove, Bonktown, and Dickies Girl (which aren't nearly as titillating as
they sound, and QuiteSFW). Still, who needs to compromise a CA when you have
these things floating around on multihomed hosts and CDNs.
Ian Grigg pointed out that this is also an EV certificate, I'm guessing that
CDNs and multihomed hosts run into the same system-high problem that dogged
MLS systems in the 1980s, they have to use the certificate at the highest
level of any of the constituent domains. So if you compromise (say)
inpath-static.iseatz.com (which consists of a page that says We're sorry, but
something went wrong) or images.vrbo.com (Directory Listing Denied) then
you have an EV-validated site. So the overall EV security becomes that of the
least secure co-hosted domain.
I've tried connecting to the above site with HTTPS and get a normal non-EV
Sybil certificate even though it's rooted in an EV CA... well, pseudo-rooted,
the root is then signed by an old Entrust certificate, and the certificate
itself is another multi-domain one, for Delta, Amtrak, Air France, KLM, Alaska
Air, and others. I wonder if they have some context-specific way to override
EV on a per-site basis when it's used with Sybil certificates? At the moment
it's rather hard to test because depending on where you are in the world you
get different views of servers and certificates (for example when I connect to
ISACA, which is an EV site, I get a standard non-Sybil certificate that's only
valid for ISACA), and finding a particular hostname in a Sybil certificate
doesn't mean that you'll see that particular certificate when you connect to
the server.
(Again, not wanting to pick on ISACA here, but finding a security audit
organisation sharing a certificate with Dickies Girl is kinda funny. You'd
think there'd be a security audit process to catch this :-).
What a mess! A single XSS/XSRF/XS* attack, or just a plain config problem,
and the whole house of cards comes down.
(For the TLS folks, SNI (a client-supplied Server Name Indication when it
connects) won't fix this because (a) it's not widely-enough supported yet and
(b) the server admin would have to buy 107 separate certificates to do the
job that's currently done by one Sybil certificate, and then repeat this for
every other Sybil certificate they use).
666 2633: SEQUENCE {
6703: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
675 2624: OCTET STRING, encapsulates {
679 2620: SEQUENCE {
683 15: [2] 'edgecastcdn.net'
700 18: [2] 'ne.edgecastcdn.net'
720 21: [2] 'minitab.fileburst.com'
743 30: [2] 'cdn.montimbrenligne.laposte.fr'
775 27: [2] 'zeroknowledge.fileburst.com'
804 23: [2] 'images.goldstarbeta.com'
829 25: [2] 'radialpoint.fileburst.com'
856 19: [2] 'wac.edgecastcdn.net'
877 22: [2] 'ne.wac.edgecastcdn.net'
901 19: [2] 'images.goldstar.com'
922 15: [2] 'images.vrbo.com'
939 12: [2] 'cdn.vrbo.com'
953 18: [2] 'content.truste.com'
973 13: [2] 'e1.boxcdn.net'
988 13: [2] 'e2.boxcdn.net'
1003 13: [2] 'e3.boxcdn.net'
1018 25: [2] 'privacy-policy.truste.com'
1045 13: [2] 'www.sonos.com'
1060 19: [2] 'www.dickiesgirl.com'
1081 26: [2] 'static-cache.tp-global.net'
1109 29: [2] 'images.homeawayrealestate.com'
1140 14: [2] 'cdn.verint.com'
1156 13: [2] 'swf.mixpo.com'
1171 21: [2] 'cdn.traceregister.com'
1194 14: [2] 's.tmocache.com'
1210 17: [2] 's.my.tmocache.com'
1229 23: [2] 'ne1.wpc.edgecastcdn.net'
1254 23: [2] 'gp1.wpc.edgecastcdn.net'
1279 23: [2] 'gs1.wpc.edgecastcdn.net'
1304 23: [2] 'ne1.wac.edgecastcdn.net'
1329 23: [2] 'gp1.wac.edgecastcdn.net'
1354 23: [2] 'gs1.wac.edgecastcdn.net'
1379 24: [2] 'c1.socialcastcontent.com'
1405 21: [2] 'www.steepandcheap.com'
1428 22: [2] 'www.whiskeymilitia.com'
1452 17: [2] 'www.chainlove.com'
What if you had a very good entropy source, but only practical at crypto engine installation time?
See http://www.connotech.com/doc_pudec_descr.html . (OK, it's also practical whenever the server needs servicing by trusted personnel.) Then, you care about the deterministic PRNG properties, the secrecy of its current state, and the prevention of PRNG output replays from an out-of-date saved state. And bingo, you solved the random secret generation issue satisfactorily! Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Encryption and authentication modes
Hi Florian, can I ask what your interest in AEAD is? Is there a particular application that you have in mind? DJ provided a good summary of CCM and GCM. To add some follow-on to that, RFC 5116 defines an interface to an AEAD algorithm, and a registry of such algorithms. TLS 1.2 ties into this interface, though currently only GCM is defined in TLS. Both GCM and CCM are defined for use in IPsec, and GCM is in Suite B. The other AEAD algorithm that's been defined is SIV mode; AFAIK it has not been in any standards to date. On Jul 14, 2010, at 10:22 AM, d...@deadhat.com wrote: What's the current state of affairs regarding combined encryption and authentication modes? I've implemented draft-mcgrew-aead-aes-cbc-hmac-sha1-01 (I think, I couldn't find test vectors), The motivations for aead-aes-cbc-hmac-sha1 were 1) to match legacy situations in which only the older algorithms are available, and 2) to define an AEAD algorithm that does not need a unique IV (a randomized algorithm in the terms of RFC5116). The draft could probably be re-spun to better meet goal #1, though I am not sure how important that goal is. In general, it would be valuable to have a randomized algorithm, though it would be preferable to have one that met the higher performance standard of GCM, which anything CBC based won't meet. More recently Justin Troutman has expressed an interest in possibly carrying forward work on generic composition; I've copied him. but I later came across CCM and EAX. CCM has the advantage of being NIST-reviewed. EAX can do streaming (but that's less useful when doing authentication). Neither seems to be widely implemented. But both offer a considerable reduction in per-message overhead when compared to the HMAC-SHA1/AES combination. Are there any other alternatives to consider? Are there any traps I should be aware of when implementing CCM? -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com CCM is widely implemented. It's a matter of where you look. Down at the MAC layer, AES-CCM has proved popular in wireless packet communication because it is well adapted for separating the treatment of the header as plaintext AAD from the packet body as ciphertext. Also it is relatively efficient to implement in hardware since it relies only on a single AES encrypt block cipher and the birthday resistance of the ciphertext MAC reduces on-air per packet overhead. This is the why for example that you see AES-CCM in wireles USB, 802.11, 802.16 and WiMAX management protocols. A couple of years after 802 went for AES-CCM, AES-GCM became the 802.3/ethernet choice since it is more parallelizable and so can be implemented for 10Gbps+ links where CCM becomes trickier. The per packet overhead is higher, but bandwidth on wires is cheap. I don't think you can really implement CCM except in the context of a more detailed specification for a protocol. CCM is a flexible specification and protocols that use it must nail down a number of parameters and field sizes in order to be interoperable. It's not so easy to just plug it in which makes is less convenient for the more pluggable software based protocols higher up the stack. That's true, though there are some particular CCM parameter choices made in http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml Some technically good candidates for standards adoption, E.G. OCB met resistance due to licensing issues. OCB is very attractive in software, but GCM is more efficient in hardware because it can be implemented without pipeline stalls. GCM can perform well in software, though it can't be as compact as CCM, and it excells with SIMD (http://eprint.iacr.org/2009/129) or modest hardware support like Intel's new PCLMULQDQ instruction (http://www.drdobbs.com/security/218102294;jsessionid=GMTY4RCFLHBMRQE1GHOSKHWATMY32JVN?pgno=3 ). regards, David DJ - 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
Re: A mighty fortress is our PKI
Peter Gutmann writes: Readers are cordially invited to go to https://edgecastcdn.net and have a look at the subjectAltName extension in the certificate that it presents. Also, keep your eye on: https://www.defcon.org/html/defcon-18/dc-18-speakers.html#Eckersley - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
ADMIN: your wonderful anti-spam software
Researchers at two major institutions are informed that you may have missed a recent short thread about a content delivery network with an EV cert claiming to be valid for a truly vast number of zones, originated by Peter Gutmann. I would name the institutions, but that wouldn't be a kindness. If you haven't seen this email, it is because your email managers have decided that the presence of certain strings in incoming email is forbidden. I would name those strings, but that would prevent you from seeing this email. If you haven't seen the messages I'm talking about, though, you might ask your Friendly Neighborhood Email Admin to check their logs and perhaps adjust their settings. -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
