Re: Dutch Transport Card Broken
On Thu, Jan 31, 2008 at 11:12:45PM -0500, Victor Duchovni wrote: On Fri, Feb 01, 2008 at 01:15:09PM +1300, Peter Gutmann wrote: If anyone's interested, I did an analysis of this sort of thing in an unpublished draft Performance Characteristics of Application-level Security Protocols, http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf. It compares (among other things) the cost in RTT of several variations of SSL and SSH. It's not the TCP RTTs that hurt, it's all the handshaking that takes place during the crypto connect. SSH is particularly bad in this regard. Thanks, an excellent reference! Section 6.2 is most enlightening, we were already considering adopting HPN fixes in the internal OpenSSH deployment, this provides solid material to motivate the work... To be fair, the handbrake in SFTP isn't -- the clients and servers should be using async I/O and support interleaving the transfers of many files concurrently, which should allow the peers to exchange data as fast as it can be read from disk. The same is true of NFS, and keep in mind that SFTP is more of a remote filesystem protocol than a file transfer protocol. But nobody writes archivers that work asynchronously (or which are threaded, since, e.g., close(2) has no async equivalent, and is required to be synchronous in the NFS case). And nobody writes SFTP clients and server that work asynchronously. But, we could, and we should. And the handbrake in the SSHv2 connection protocol has its rationale as well (namely to allow interactive sessions to be responsive). As described in Peter's paper, it can be turned off, effectively. It's most useful when mixing interactive sessions and X11 display forwarding (and port forwarding which don't involve bulk data transfers). It's most useless when doing bulk transfers. So use separate connections for bulk transfers. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: questions on RFC2631 and DH key agreement
I'd scrawled..
Other than for b perhaps wanting to verify the correctness of { p, q, g,
j } (group parameter validation), is there any reason to send q ?
[EMAIL PROTECTED] replied:
I would actually recommend sending all the public data. This does not take
significant additional space and allows more verification to be performed.
That's what I thought.
BTW, I'm not myself working on something employing a DH exchange -- I'm
analyzing/reviewing something that does.
I would also suggest looking at what exactly the goal is. As written this
provides no authentication just privacy,
Indeed, b could be any entity because it isn't proving possession of any
known-only-to-it information.
and if b uses the same private key
to generate multiple yb the value of b['s private key?] will slowly leak.
Yep, I suspected that too. Thanks.
So, another question or two:
If a purportedly secure protocol employing a nominal DH exchange in order to
establish a shared secret key between a requester and responder, employs
widely known published (on the web) fixed values for g (2) and p (a
purportedly prime 1040 bit number) for many of it's implementations and
runtime invocations, what are the risks its designers are assuming with
respect to the resultant properties of ZZ?
I suspect that many implementations will simply use the equivalent of whatever
rand() function is available to get the bits for their private keys directly,
and will likely not reallocate private keys unless the implementation or
machine are restarted. So if the random number generator has known flaws, then
there may be some predictability in both the public keys and in ZZ, yes?
Additionally there's the previously noted issue with the values of static
private keys slowly leaking.
thanks again,
=JeffH
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Anne Lynn Wheeler [EMAIL PROTECTED] write: one of my favorite exchanges from the mid-90s was somebody claiming that adding digital certificates to the electronic payment transaction infrastructure would bring it into the modern age. my response was that it actually would regress the infrastructure at least a couple decades to the time when online, real-time transactions weren't being done. The online, real-time transaction provides much higher quality and useful information than a stale, static digital certificate (with an offline paradigm from before modern communication). Having an available repository about the party being dealt with ... including things like timely, aggregated information (recent transactions) is significantly mover valuable than the stale, static digital certificate environment (the only thing that it has going for it, is it is better than nothing in the oldtime offline environment). [...] EU had also made a statement in the mid-90s that electronic retail payments should be as anonymous as cash. They can't be as anonymous as cash if the party being dealt with can be identified. And the party can be identified if the transaction is online, real-time. Even if other clues are erased, there's still traffic analysis in this case. What the offline paradigm has going for it is the possibility of true, untraceable anonymity through the use of anonymizing remailers and related technologies. -- StealthMonger [EMAIL PROTECTED] -- stealthmail: Scripts to hide whether you're doing email, or when, or with whom. http://stealthsuite.afflictions.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
-- Ivan Krstic' wrote: The wider point of Peter's writeup -- and of the therapy -- is that developers working on security tools should _know_ they're working in a notoriously, infamously hard field where the odds are _overwhelmingly_ against them if they choose to engineer new solutions. That point is of course true. But the developers wanted to transport IP and UDP. Peter should have known that SSL is incapable of transporting IP and UDP, because it will introduce large, unpredictable, and variable delays. If, for example, VOIP goes over SSL, the speakers would become entirely unintelligible. So yes, the developers were incompetent in that they badly underestimated the difficulty of the task. And Peter was incompetent in thinking that one layer of a solution for a particular problem can be plucked out of that environment, an environment where it works very badly, and plonked into another, very different, environment. Not only do new solutions generally not work, but existing solutions generally work badly, and are commonly inapplicable outside their particular special environment. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
At 09:34 PM 2/1/2008 +0100, Ian G wrote: * Browser vendors don't employ security people as we know them on this mailgroup, they employ cryptoplumbers. Completely different layer. These people are mostly good (and often very good) at fixing security bugs. We thank them for that! But they are completely at sea when it comes to systemic security failings or designing new systems. An excellent observation Ian!! I too have run into this mindset at enterprises with inhouse security teams (mostly in Silicon Valley). They focus on the nuts and bolts like producing/using cryptographic libaries, fixing security bugs in code or configuring network appliances to stop intrusions. But it is really hard to find any of them with decent experience or knowledge at the overall software/hardware/people system design level. They are often very smart and educated engineers. I find that there's this mindless focus on using groups of security standards, e.g PKI / LDAP / SSL type of combinations, etc. The DoD contractor firms seem to be a little bit better at recognizing the system level aspects of security, although they too are often blinded by the emphasis on COTS security products. - Alex -- Alex Alten [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Interesting editorial comment on security vs. privacy
http://www.claybennett.com/pages/security_fence.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
StealthMonger wrote: They can't be as anonymous as cash if the party being dealt with can be identified. And the party can be identified if the transaction is online, real-time. Even if other clues are erased, there's still traffic analysis in this case. What the offline paradigm has going for it is the possibility of true, untraceable anonymity through the use of anonymizing remailers and related technologies. most people who heard the statement, understood that. i think that possibly 2nd level detail was that they didn't want PII easily associated by casual merchant. Initial response was to remove name from payment cards magstripes. This also precluded merchants from requesting other forms of identification to see if the names matched the name on the payment card. The implication being that the payment infrastructure would have to come up with other mechanisms to improve the infrastructure integrity. The offline payment paradigms ... while touting true anonymity were actually primarily justified based on other factors. We had been asked to design and cost the dataprocessing supporting US deployments of some of the offline products (that were being used in Europe). Along the way, we did some business process and revenue analysis and realized that the primary motivation behind these system deployments was the float. About the same time that there was the EU about the privacy of electronic retail payments ... there was also a statement by the EU (and some of the country central banks) that the offline products would be allowed to keep the float for a short grace period to help in the funding of the infrastructure deployment ... but after the grace period ... the operators would have to start paying interest on the balance held in the offline instruments (eliminating float from the equation). After that, much of the interest in the offline deployments drifted away. In that time frame we had also done design, implementation and deployment of a payment transaction infrastructure supporting target marketing ... recent reference http://www.garlic.com/~lynn/2008c.html#27 Diversity support was for a small pilot of 60mil accounts and 1.5million transaction/day ... but capable of scaling up to 20-30 times that amount. There was significant attention paid to privacy issues and it was subject to quarterly auditing by some dozen or so privacy organizations. there had to be a large amount of sensitive treatment of the information along the lines of what HIPAA specifies for health information. aka: anonymized Previously identifiable data that have been deidentified and for which a code or other link no longer exists. An investigator would not be able to link anonymized information back to a specific individual. [HIPAA] (see also anonymous, coded, directly identifiable, indirectly identifiable) as part of co-authoring x9.99 financial privacy standard, one of the things we created was a privacy merged glossory and taxonomy ... including GLBA, HIPAA, and EU-DPD references some notes: http://www.garlic.com/~lynn/index.html#glosnote in our work on x9.59 financial transaction standard http://www.garlic.com/~lynn/x959.html#x959 we made the statement that it was privacy agnostic ... since the transactions were tied to accounts ... but then whether or not the accounts were tied to individuals was outside the x9.59 standard http://www.garlic.com/~lynn/subpubkey.html#x959 As a total aside ... as part of the Digicash liquidation, we were brought in to evaluate the patent portfolio. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Gutmann Soundwave Therapy
At Sun, 03 Feb 2008 12:51:25 +1000, James A. Donald wrote: -- Ivan Krstic' wrote: The wider point of Peter's writeup -- and of the therapy -- is that developers working on security tools should _know_ they're working in a notoriously, infamously hard field where the odds are _overwhelmingly_ against them if they choose to engineer new solutions. That point is of course true. But the developers wanted to transport IP and UDP. Peter should have known that SSL is incapable of transporting IP and UDP, because it will introduce large, unpredictable, and variable delays. If, for example, VOIP goes over SSL, the speakers would become entirely unintelligible. For those who haven't already made up their minds, the situation with VoIP and TCP (SSL doesn't really change the situation) is actually a bit more complicated than this. 1. VoIP over TCP If you have a reasonably fast loss-free channel (this isn't that uncommon) then it doesn't actually make an enormous amount of difference whether you're running TCP or UDP, especially if you're running a high-bandwidth codec like G.711. It helps to turn off the Nagle algorithm, of course, since it reduces the amount of buffering in the sending TCP stack. That said, any significant amount of packet loss does tend to create some pretty significant artifacts, since you need to stall the receiving TCP while you wait for the retransmit. So, as a practical matter nearly all interactive VoIP systems use UDP and some kind of packet loss concealment (interpolation, etc.). That's not to say that SSL/TLS is totally innocent here. The designers of SSL/TLS *could* have chosen to design a protocol which would work over datagram transport as well as stream transport, but they didn't. DTLS (RFC 4347) is such a protocol. That said, if you compare DTLS to TLS, there is a small amount of additional complexity in DTLS, so it's arguable that it was a good design choice to go for the sweet spot of stream transport, since that's what SSL was really intended for. 2. VoIP over DTLS As Perry indicated in another message, you can certainly run VoIP over DTLS, which removes the buffering and retransmit issues James is alluding to. Similarly, you could run VoIP over IPsec (AH/ESP). However, for performance reasons, this is not the favored approach inside IETF. The relevant issue here is packet size. Say you're running a low bandwidth codec like G.729 at 8 kbps. If you're operating at the commonly used 50 pps, then each packet is 160 bits == 20 bytes. The total overhead of the IP, UDP, and RTP headers is 40 bytes, so you're sending 60 byte packets. - If you use DTLS with AES in CBC mode, you have the 4 byte DTLS header, plus a 16 byte IV, plus 10 bytes of MAC (in truncated MAC mode), plus 2 bytes of padding to bring you up to the AES block boundary: DTLS adds 32 bytes of overhead, increasing packet size by over 50%. The IPsec situation is similar. - If you use CTR mode and use the RTP header to form the initial CTR state, you can remove all the overhead but the MAC itself, reducing the overhead down to 10 bytes with only 17% packet expansion (this is how SRTP works) Note that some (but not all) of the gain from SRTP can be obtained by swapping CTR for CBC. But you're still getting an advantage from being willing to overload the RTP header and that's harder to optimize out (though Nagendra Modadugu and I spent some time thinking about this). I don't propose to get into an extended debate about whether it is better to use SRTP or to use generic DTLS. That debate has already happened in IETF and SRTP is what the VoIP vendors are doing. However, the good news here is that you can use DTLS to key SRTP (draft-ietf-avt-dtls-srtp), so there's no need to invent a new key management scheme. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
