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]
Re: Gutmann Soundwave Therapy
"James A. Donald" <[EMAIL PROTECTED]> writes: > 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. That's just plain factually wrong. DTLS does fine for that purpose. At the point where you are sending datagrams with voice data, you're just doing conventional crypto over a fixed length packet each time, and those algorithms are quite deterministic. Indeed, DTLS was designed specifically for such applications. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
TCP, SSL, SSH, TLS, HTTP and other tools of mass...
The title on this post is not fair, I agree. The real question I want to ask is, "Do we ever get it *right* the first time?" Let's step outside cryptography to look at a possible answer and avoid the traps inherent in discussing current politics. From 1908 to 1927 more than 15 million Model Ts were built. The Model T got a bunch of things right. Availability, mileage that we are only now exceeding in a mass way, simplicity. It only took oatmeal, chewing gum and bailing wire to keep it running. ;-> And it managed all this when roads were hardly more than muddy ruts. The use of vanadium steel was one of the key right things as well and is part of the reason why many still are running. And it got a bunch of things wrong, not always on purpose, but rather that they had not had enough experience to understand *what* was wrong. My dad told me that learning to drive one was more than a bit of a challenge given the hodge podge of controls and they way they interacted. If I recall correctly second gear and the emergency brake were controlled by the same lever to the left of the driver. One of the other things to remember that it cost $850 in 1908 and about $300 by 1927. Figuring inflation into the price and it probably only cost $150 or less in 1908 dollars A lot of this is like early computer interconnects and their controls. Think back 19 years and what was it like? My memory is that it was a lot like the early days of cars before the Model T. All the discussion about the weaknesses and strengths of the various controls seems a lot like car manufacturing before the Model T. So, if history tends to repeat itself, I'd expect a Model T to be about where we are now, and we should start planning for its replacement. If we learn from the history of the evolution of the car we might be able to avoid some of the pitfalls of Edsels, tailfins and other geegaws. But don't bet on it or hold your breath. So, back to the core question, did we get the Internet and its controls right the first time? Nope. Will we get it right the second time? Nope. Will we ever get it right? Nope. My feeling is that all the discussions about the limitations or advantages of what we have right now in terms of controls takes our eyes off of change, for change *will* happen whether we like it or not. And not all of it will be for the better as we have seen with recent events around identity theft, phishing, XSS, etc. And, of course, the big fish swallowing the littler fish, making for a mono culture very prone to an unexpected disease. We might be able to reduce the missteps if we concentrate on keeping what works and only fiddling with that which is weak. Hope ever, hope on. Best, Allen - 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: 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]
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: 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: 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: 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]
