More info in my AES128-CBC question
Hi Folks, First, thanks for all your answers. The proposal for using AES128-CBC with a fixed IV of all zeros is for a protocol between two entities that will be exchanging messages. This is being done in a standards body (OMA) and many of the attendees have very little security experience. As I mentioned, the response to my question of why would we standardize this was that's how SD cards do it. I'll look at the references and hopefully convince enough people that it's a bad idea. Thanks again, Aram Perez - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto component services - is there a market?
Ian, Hmmm... last I heard, qualified certificates can only be issued to individuals, and invoicing (of the e-form that the regulations speak) can only be done by VAT-registered companies. True. Is that not the case? How is Germany resolving the contradictions? By using pseudonyms within the certificate's common name. This is not only done in Germany but in other countries as well. Even CAs (and, at least in Germany, the root CA) are being issued qualified certificates, thus they need to use pseudonyms. The timestamping service by Deutsche Post, e.g., has a qualified certificate with the following DN: Subject DN : CN = TSS DP Com 31:PN OU = Signtrust O = Deutsche Post Com GmbH C = DE Since electronic invoices need to be archived in most countries some vendors apply time-stamps and recommend to re-apply time-stamps from time to time. Easier to invoice with paper! potentially much more expensive, though. Cheers, Stefan. T.I.S.P. - Lassen Sie Ihre Qualifikation zertifizieren vom 25.-30.06.2007 - http://www.secorvo.de/college/tisp/ Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Ettlinger Strasse 12-14, D-76137 Karlsruhe Tel. +49 721 255171-304, Fax +49 721 255171-100 [EMAIL PROTECTED], http://www.secorvo.de/ PGP: 87AE E858 CCBC C3A2 E633 D139 B0D9 212B Mannheim HRB 108319, Geschaeftsfuehrer: Dirk Fox - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
On Thu, Apr 19, 2007 at 10:32:58PM -0700, Aram Perez wrote: Hi Folks, First, thanks for all your answers. The proposal for using AES128-CBC with a fixed IV of all zeros is for a protocol between two entities that will be exchanging messages. This is being done in a standards body (OMA) and many of the attendees have very little security experience. As I mentioned, the response to my question of why would we standardize this was that's how SD cards do it. I'll look at the references and hopefully convince enough people that it's a bad idea. You still have not described the protocol, or how keys are used/managed. The question has no answer outside the context of a specific protocol, other than in general it is best practice to use random IVs or otherwise unlikely to repeat IVs. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
On Thu, 19 Apr 2007 22:32:58 -0700 Aram Perez [EMAIL PROTECTED] wrote: Hi Folks, First, thanks for all your answers. The proposal for using AES128-CBC with a fixed IV of all zeros is for a protocol between two entities that will be exchanging messages. This is being done in a standards body (OMA) and many of the attendees have very little security experience. As I mentioned, the response to my question of why would we standardize this was that's how SD cards do it. I'll look at the references and hopefully convince enough people that it's a bad idea. Let me make a stronger statement. If the standards group has very little security experience, they *will* get many things wrong. They desperately need to get several clueful individuals involved and *listen* to them. The WEP group made that mistake. I use WEP in my classes as a case study in how to do crypto wrong. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More info in my AES128-CBC question
Aram Perez wrote: The proposal for using AES128-CBC with a fixed IV of all zeros is for a protocol between two entities that will be exchanging messages. This is being done in a standards body (OMA) and many of the attendees have very little security experience. We don't let a bunch of random people design airbags. How on earth is it a good idea to let a random bunch of people design crypto protocols? Is this the same bunch of people that will be shocked, just SHOCKED when someone demonstrates that their design is idiotic and doesn't protect anyone or anything? No, really, that people with very little security experience feel comfortable doing this kind of work just boggles my mind. Please congratulate everyone involved, and remind them to always use their PPTP VPN over their WEP-protected wireless. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto component services - is there a market?
Stefan Kelm wrote: Same with digital timestamping. Here in Europe, e-invoicing very slowly seems to be becoming a (or should I say the?) long-awaited application for (qualified) electronic signatures. Since electronic invoices need to be archived in most countries some vendors apply time-stamps and recommend to re-apply time-stamps from time to time. When I was in business in the UK (until last year) (as a VAT-registered individual) I issued electronic invoices when convenient to my clients. I found no general requirement for any signature, let alone a qualified electronic one; I had a professional obligation to sign invoices, which I met by the inclusion of a graphic of a handwritten signature. Invoices were dated and copies kept, but there was no requirement for time-stamping or any particular evidence of date of delivery. I received and continue to receive electronic invoices from time to time, but none appear to be digitally signed, nor have I seen evidence of time-stamping in operation. Nicholas -- Salkyns, Great Canfield, Takeley, Bishop's Stortford CM22 6SX, UK Phone 01279 870285(+44 1279 870285) Mobile 07715 419728(+44 7715 419728) PGP public key ID: 0x899DD7FF. Fingerprint: 5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto component services - is there a market?
re: http://www.garlic.com/~lynn/aadsm26.htm#60 crypto component services - is there a market slightly related discussion of x9.59 financial standard protocol http://www.garlic.com/~lynn/x959.html#x959 supporting hash of invoice in any dispute resolution ... thread from a couple weeks ago http://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services http://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services where the x9.59 transaction is digital signed (and presumably logged/archived as part of various financial regulations). In dispute, both parties can produce their version of any invoice (bill of materials, etc) and differences can be resolved by the hash included in the signed payment transaction. In the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments. It faced a couple issues 1) It was starting to dawn that x.509 identity certificates from the early 90s, frequently overloaded with personal information represented significant privacy and liability issues. As a result there was move to digital certificates that contained some sort of indirect (and/or obfuscated) lookup value ... and were frequently referred to as relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo however, it was trivial to show that in any situation where the indirection had to be used for some sort of lookup ... that the public key could be obtained in the same operation ... making the digital certificate redundant and superfluous 2) Some of the other digital signed work for financial transactions in the period ... the appending of a digital certificate to such a transaction was resulting in two orders magnitude payload and processing bloat (for something that was redundant and superfluous) http://www.garlic.com/~lynn/subpubkey.html#bloat 3) The appending of the digital certificate is basically a paradigm operation that supports distribution of trusted information for offline operation (the electronic analog of physical credential, certificate, license, and/or letters of credit/introduction from sailing ship days and earlier). At the time we were working on x9.59 ... there were several claiming that the appending of digital certificates (to financial transactions) was needed to bring financial processing into the modern age. Our reply was that moving from a fundamentally online infrastructure to an offline paradigm actually represented a regression of several decades. It was somewhat after that you started to see work on the rube goldberg OCSP standard. In some respect ... trusted time-stamping is attempting to take the online financial transaction model where there are frequently strict regulations about archiving/auditing and extend it to other types of operations. In the x9.59 financial standard scenario ... the financial archiving/auditing infrastructure was extended to cover invoice, bill-of-materials, etc ... but simply adding their hash to the digital signed financial transaction (and at the same time avoiding the enormous payload and processing bloat seen in various other strategies). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
