Re: anonymous DH MITM
I'm lost in a twisty page of MITM passages, all alike. My point was that in an anonymous protocol, for Alice to communicate with Mallet is equivalent to communicating with Bob, since the protocol is anonymous: there is no distinction. All the concept of MITM is intended to convey is that in an anonymous protocol, you don't know who you're talking to, period. Mallet having two conversations with Alice Bob is equivalent to Mallet intermediating himself into a conversation between Alice Bob. If you have some unintermediated channel to speak with a known someone once, you can exchange a value or values which will allow you to authenticate each other forevermore and detect any intermediations in the past. But the fundamental truth is that there's no way to bootstrap a secure communication between two authenticated parties if all direct indirect communications between those parties may be intermediated. (Call this the 'brain in a jar' hypothesis.) - Tim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
On Fri, 3 Oct 2003, Benja Fallenstein wrote: bear wrote: Why should this not be applicable to chess? There's nothing to prevent the two contestants from making nonce transmissions twice a move when it's not their turn. I.e., you would need a protocol extension to verify the nonces somehow-- if that's possible at all-- or are you just faster than me, and have thought about a way to do that already? Not faster per se, but I do happen to know the solution to that problem. :-) Suppose Alice picks a nonce A(zero). Then for n=one to a thousand (presumably no chess game will last 1000 moves) she calculates A(n) = hash (A(n-1)). Note, this has to be a ONE WAY hash function rather than any kind of encryption that can be decrypted. I'd suggest seventeenth-power mod K where K is prime, but lots of good irreversible hashing functions that aren't so expensive in CPU cycles are around. Bob also picks a nonce B(zero) on his side, and produces the same kind of sequence of B(one...one thousand) using the same hash function. Now let the moves of the chess game be numbered from 1000 down to 0. (ie, the first move they play will be move 1000, the second will be move 999, etc.) When it's Bob's turn, he sends his move padded with B(n), and Alice sends a random move padded with A(n). When it's Alice's turn, she sends her move padded with A(n) and Bob sends a random move padded with B(n). Bob can rapidly check to make sure that the A(n) recieved with each message has the right relation to the A(n+1) he recieved with the previous move, but there is no way he (or Mitch) can possibly predict A(n-1) to know what he'll get in the next move. Likewise Alice can rapidly check to make sure that the B(n) recieved with each move has the right relation to the B(n+1) she recieved with the previous move, but there is no way she (or Mitch) can predict B(n-1) to know what she'll get the next move. The only change to the rules of chess this requires is that if they ever exhaust the finite sequence of generated nonces, they have to call that game a draw. But a thousand moves, really, shouldn't be a problem for chess, and if it is you can just make the sequence longer and start a new game. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
| From: Tim Dierks [EMAIL PROTECTED] | | I'm lost in a twisty page of MITM passages, all alike. | | My point was that in an anonymous protocol, for Alice to communicate with | Mallet is equivalent to communicating with Bob, since the protocol is | anonymous: there is no distinction. All the concept of MITM is intended to | convey is that in an anonymous protocol, you don't know who you're talking | to, period. Mallet having two conversations with Alice Bob is equivalent | to Mallet intermediating himself into a conversation between Alice Bob. | | If you have some unintermediated channel to speak with a known someone | once, you can exchange a value or values which will allow you to | authenticate each other forevermore and detect any intermediations in the | past. But the fundamental truth is that there's no way to bootstrap a | secure communication between two authenticated parties if all direct | indirect communications between those parties may be intermediated. (Call | this the 'brain in a jar' hypothesis.) OK, let's set up two different scenarios: 1. Non-anonymous communication. Alice talks to Bob. Alice knows Bob is on the other end, Bob knows Alice is on the other end. They share some secret data; Alice wishes it to be known only to her and Bob. Mallet has a bug in Bob's home and copies the data. Can Alice or Bob detect that Mallet is there? Clearly not if Mallet never uses the data in a detectable way. No matter how many times Alice and Bob communicate, whether or not Mallet continues to bug Bob, neither Alice nor Bob can never learn of Mallet's presence. 2. Anonymous communication. Alice and Bob have a conversation. Mallet plays MITM. Alice and Bob don't know who their corresponding partner is, but they each tell the other that they will not reveal the secrets they exchange, and each believes the other - and indeed neither ever reveals those secrets. They wish to know if anyone else had a chance to learn their secret. On the face of it, there's no difference between these two cases. In each case, someone receives a copy of the secrets exchanged between Alice and Bob, but doesn't *do* anything with them that either Alice or Bob can see. However, in this case, unlike 1, if Alice and Bob continue to communicate - using private pseudonyms for each other to make continue to communicate a meaningful phrase - then, assuming Mallet cannot *always* interpose himself, they will eventually discover that someone has played a MITM game on them. If, indeed, you have a full brain in a jar, and Mallet *always* manages to interpose himself, then, yes, this situation is almost certainly undetectable. I've learned not to make snap judgements on stuff like this - too many clearly impossible things turn out not to be. In fact, I find the distinction between cases 1 and 2 quite surprising! -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protocol implementation errors
Bill Frantz [EMAIL PROTECTED] writes: This is the second significant problem I have seen in applications that use ASN.1 data formats. (The first was in a widely deployed implementation of SNMP.) Given that good, security conscience programmers have difficultly getting ASN.1 parsing right, we should favor protocols that use easier to parse data formats. I think this leaves us with SSH. Are there others? I would say the exact opposite: ASN.1 data, because of its TLV encoding, is self-describing (c.f. RPC with XDR), which means that it can be submitted to a static checker that will guarantee that the ASN.1 is well-formed. In other words it's possible to employ a simple firewall for ASN.1 that isn't possible for many other formats (PGP, SSL, ssh, etc etc). This is exactly what cryptlib does, I'd be extremely surprised if anything could get past that. Conversely, of all the PDU-parsing code I've written, the stuff that I worry about most is that which handles the ad-hoc (a byte here, a unit32 there, a string there, ...) formats of PGP, SSH, and SSL. We've already seen half the SSH implementations in existence taken out by the SSH malformed-packet vulnerabilities, I can trivially crash programs like pgpdump (my standard PGP analysis tool) with malformed PGP packets (I've also crashed quite a number of SSH clients with malformed packets while fiddling with my SSH server code), and I'm just waiting for someone to do the same thing with SSL packets. In terms of safe PDU formats, ASN.1 is the best one to work with in terms of spotting problems. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
OOAPI-SSL/TLS (Was: Simple SSL/TLS - Some Questions)
On Fri, Oct 03, 2003 at 05:55:25PM +0100, Jill Ramonsky wrote: Having been greatly encouraged by people on this list to go ahead with a new SSL implementation, That's a pretty good idea, I also encourage you (and volunteer to support). The main point of confusion/contention right now seem to be (1) should it be in C or C++?, I definitely vote for C++ for several reasons. You already mentioned plenty of reasons yourself, the security advantages of C++. But be warned: In contrast to modern scripting languages C++ is not automatically immune against buffer overruns etc. It takes some discipline to have a good programming style in C++. The main advantage I see is the oportunity to have a good, object oriented design of the API to give an example of a good and usable Crypto API. Everyone here has his own favourite language, I meanwhile prefer Ruby. I had to write a CA some months ago and didn't find a good language with SSL and Certificate management support, except for Ruby. Michal Rokos [EMAIL PROTECTED] was currently writing the glue code to use the openssl library with ruby, and I found it very comfortable to use SSL from a scripting language. It was however a big heap of debugging, reading the openssl API and source code, discussing requirements with Michal, ask him for extensions etc., since it is quite difficult, to implement all features of openssl, and many of them are not logical. This project showed the shortcomings of openssl, it is not really a usable and complete software. This causes insecurity, because it is too difficult for application writers to use it and to support all features. I'd therefore propose the following: To design two (ore more) object oriented APIs for - cryptographic primitives - non-communication oriented functions (key and certificate management, S/MIME message handling, ...) - communication oriented functions (SSL/TLS) but to not stick too tight to C++. The design must be applicable to all modern object oriented languages. Then do a C++ implementation of the API (spell: header files) and see, whether this is possible without tricks. Also have the API defined in other languages such as Python, Ruby, Java,... Take care that the design is easy to read, easy to understand, easy to debug. Make use of object oriented design where possible. Now implement the library itself in C++, while others write the glue code for other languages simultaneously. As a result, there will be a language-independend object-oriented Meta-API, describing the library virtually for all languages. For every supported language there is a translated API of this and a library to use. For C++, this is a genuine library, for other languages this will be glue code + the C++ library. This would be a step to bring secure programming a step forward towards modern programming, and to ease and support use of SSL/TLS/... I am currently quite happy with the way Michal Rokos wrapped openssl into an object oriented API, but it would be good to have this in more languages, it still allows improvements and is still incomplete. regards Hadmut - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Strong-Enough Pseudonymity as Functional Anonymity
I can think of three different goals one could have for identifying the person behind a name. If goal A is possible, I say that the name was a verinym. If goal C is possible, I say that the name was a pseudonym. If none of the goals are possible, the transaction was anonymous. Unfortunately, there's no word for the kind of name where goal B is possible but goal A isn't. Suppose Alice the Argulant visited the tavern that you own and operate in a virtual reality MUD world, and behaved badly and you had her thrown out. Goal A: figure out the real human who operates the Alice persona, and break his or her kneecaps, or at least threaten to do so, while making it clear that you have the ability to make good on your threat. Goal B: make sure that the real human who operates the Alice persona doesn't come back the next day under a different name: Bobo the Burbulant. Goal C: make sure that the real human who operates the Alice persona suffers a loss of reputation capital or escrowed gold pieces or something, thus deterring him or her from behaving badly. I imagine it might be nice to have Goal B achievable in a certain setting where Goal A remains unachievable. Regards, Zooko the Zoogulant - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
(about the Interlock Protocol) Benja wrote: The basic idea is that Alice sends *half* of her ciphertext, then Bob *half* of his, then Alice sends the other half and Bob sends the other half (each step is started only after the previous one was completed). The point is that having only half of the first ciphertext, Mitch can't decrypt it, and thus not pass on the correct thing to Bob in the first step and to Alice in the second, so both can actually be sure to have the public key of the person that made the other move. That sounds like an accurate summary to me. I think that the important thing is that the first message commits the sender to the contents while withholding knowledge of the contents from the recipient. The second message reveals the contents to the recipient. The fact that this is implemented by sending half of the ciphertext at a time seems peripheral. The same qualities would arise if this were implemented with a different commitment protocol, such as sending a secure hash of the tuple of (my_message, a_random_nonce). Regards, Zooko http://zooko.com/log.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
Thor Lancelot Simon wrote:
As far as what OpenSSL does, if you simply abandon outright any hope of
acting as a certificate authority, etc. you can punt a huge amount of
complexity; if you punt SSL, you'll lose quite a bit more. As far as the
programming interface goes, I'd read Eric's book and then think hard about
what people actually use SSL/TLS for in the real world. It's horrifying
to note that OpenSSL doesn't even have a published interface for a some of
these operations. For example, there is no simple way to do the most
common certificate validation operation: take a certificate and an optional
chain, and check that the certificate is signed by an accepted root CA, or
that each certificate in the chain has the signing property and that the
chain reaches that CA -- which would be okay if OpenSSL did the validation
for you automatically, but it doesn't, really.
Err, yes it does, but its not very well documented.
In fact, it constantly amazes me what OpenSSL does do for you
automatically. For example, I recently added CRL checking to Apache-SSL.
It took a while to figure it out, but in the end it came down to doing this:
static void InitCRL(SSLConfigRec *pConfig)
{
X509_STORE *pStore=SSL_CTX_get_cert_store(pConfig-pSSLCtx);
int vflags=0;
if(pConfig-bUseCRL)
vflags|=X509_V_FLAG_CRL_CHECK;
if(pConfig-bCRLCheckAll)
vflags|=X509_V_FLAG_CRL_CHECK_ALL;
X509_STORE_set_flags(pStore,vflags);
}
(note, before people start nagging me for it, this is a WIP, but will be
released soon).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
[EMAIL PROTECTED] wrote: On Thu, 2 Oct 2003, Thor Lancelot Simon wrote: 1) Creates a socket-like connection object 2) Allows configuration of the expected identity of the party at the other end, and, optionally, parameters like acceptable cipher suite 3) Connects, returning error if the identity doesn't match. It's probably a good idea to require the application to explicitly do another function call validating the connection if it decides to continue despite an identity mismatch; this will avoid a common, and dangerous, programmer errog. 4) Provides select/read operations thereafter. Speaking as a Postfix developer, it would be very useful to have a non-blocking interface that maintained an event bitmask and readable/writable callbacks for the communications channel, allowing a single-threaded application to get other work done while a TLS negotiation is in progress, or to gracefully time out the TLS negotiation if progress is too slow. This means that the caller should be able to tear down the state of a partially completed connection at any time without memory leaks or other problems. Again, you can do this with OpenSSL. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
On Sat, Oct 04, 2003 at 02:09:10PM +0100, Ben Laurie wrote: Thor Lancelot Simon wrote: As far as what OpenSSL does, if you simply abandon outright any hope of acting as a certificate authority, etc. you can punt a huge amount of complexity; if you punt SSL, you'll lose quite a bit more. As far as the programming interface goes, I'd read Eric's book and then think hard about what people actually use SSL/TLS for in the real world. It's horrifying to note that OpenSSL doesn't even have a published interface for a some of these operations. For example, there is no simple way to do the most common certificate validation operation: take a certificate and an optional chain, and check that the certificate is signed by an accepted root CA, or that each certificate in the chain has the signing property and that the chain reaches that CA -- which would be okay if OpenSSL did the validation for you automatically, but it doesn't, really. Err, yes it does, but its not very well documented. No. You can't do it in one step, and you have to use functions that are marked in OpenSSL's header files as not being part of the official API. mod_ssl has a convenience function that's confusingly named just like the OpenSSL library functions that deals with this -- of course, it should be part of OpenSSL itself, but at least as of 0.9.6 it was not. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Strong-Enough Pseudonymity as Functional Anonymity
Zooko O'Whielacronx wrote: I imagine it might be nice to have Goal B achievable in a certain setting where Goal A remains unachievable. In a strictly theoretical sense, isn't this essentially the job of the (perfect) TTP? At least that's the way many protocols seem to brush away the difficulty. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
bear wrote: On Fri, 3 Oct 2003, Benja Fallenstein wrote: bear wrote: Why should this not be applicable to chess? There's nothing to prevent the two contestants from making nonce transmissions twice a move when it's not their turn. I.e., you would need a protocol extension to verify the nonces somehow-- if that's possible at all-- or are you just faster than me, and have thought about a way to do that already? Not faster per se, but I do happen to know the solution to that problem. :-) Ah, good ;-) Suppose Alice picks a nonce A(zero). Then for n=one to a thousand (presumably no chess game will last 1000 moves) she calculates A(n) = hash (A(n-1)). Does it work? Assume A() is Alice's series, B() is Bob's, MA() is the one Mitch uses with Alice, MB() the one Mitch uses with Bob. - Mitch sends first half of cyphertext of MA(1000) (to Alice) - Alice sends first half of cyphertext of her move + A(1000) (to Mitch) - Mitch sends second half - Alice sends second half Mitch can now decrypt Alice's move. - Bob sends first half of cyphertext of B(1000) (to Mitch) - Mitch sends first half of cyphertext of Alice's move + MB(1000) (to Bob) - Bob sends second half. - Mitch sends second half. Bob decides on his move. - Bob sends first half of ciphertext of his move + B(999) (to Mitch) - Mitch sends first half of ciphertext of MB(999) (to Bob) - Bob sends second half. - Mitch sends second half. Mitch can now decrypt Bob's move... Am I missing something? - Benja - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OOAPI-SSL/TLS (Was: Simple SSL/TLS - Some Questions)
Rich Salz wrote: You know about Wei's Crypto++, right? I use it and like it. I don't have to dig into the guts very often, which is good because I don't like mucking around in C++. You have to understand templates to understand the API. The docs are spartan, but the design is clean so it is okay. It's difficult to compile on new platforms, new versions of compilers, etc., but that's probably true of any C++ library that doesn't deliberately restrict itself to a small subset of C++'s features. If you keep our C++ reasonably simple (no templates) then SWIG (http://www.swig.org) will make the scripting language glue code for you automatically. I use SWIG and like it. They say that the new SWIG handles templates better than good old 1.1. I haven't tried SWIG on Crypto++. I would really *like* for someone else to do so and share the results... Regards, Zooko - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
