Re: LibTomNet [v0.01]
Ian Grigg <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > > > My logic is that if you're going to create something new, it should > > be better than what already exists. > > Right. But better is not a binary choice in real > life. SSL is only "better" if it exceeds all > requirements when compared against a product > that has only those requirements. > > One needs to look at the requirements. Tom's > requirements didn't include message integrity, > if I saw correctly, because he had something > in there at a higher layer that covered him > there. That's good. That's certainly not true. He had a message integrity construct. It just didn't include anti-replay measures. > Does he require replay protection? Is he worried > about MITM? What about authenticity? These all > need to be established before you can compare any > protocol. > > The whole world doesn't want or need perfect > channel security. That's because some parts of > the world have different needs. Actually, I think this attitude is generally unproductive. All else being equal, a protocol which provides more security is better than a protocol which provides less. Now, all things aren't equal, but if you can offer substantially more security with only a modest increase in code complexity, that's generally a good thing. Where hard tradeoffs have to be made is when the users are inconvenienced. A little additional programming doesn't seem like a high cost at all. I don't find this sort of "sure, it's nowhere near as secure as secure as SSL, but it takes up a little less space" argument very compelling at all. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
Eric Rescorla wrote: > My logic is that if you're going to create something new, it should > be better than what already exists. Right. But better is not a binary choice in real life. SSL is only "better" if it exceeds all requirements when compared against a product that has only those requirements. One needs to look at the requirements. Tom's requirements didn't include message integrity, if I saw correctly, because he had something in there at a higher layer that covered him there. That's good. Does Tom require certs? No, or *even better* he explicitly outsourced that requirement to another layer, thus allowing the protocol to be simpler. This is a great thing, and my reading of the protocol of SSL - from Eric's book - indicates that SSL would benefit from it too. Does he require replay protection? Is he worried about MITM? What about authenticity? These all need to be established before you can compare any protocol. The whole world doesn't want or need perfect channel security. That's because some parts of the world have different needs. -- iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Voltage - Identity Based Encryption.
Martin, I understand your reluctance. I don't like this mechanism either and I was the CTO of Authentica! martin f krafft wrote: also sprach C. Wegrzyn <[EMAIL PROTECTED]> [2003.07.08.2324 +0200]: This is the same approach used in the Authentica system but it is deployed in an enterprise environment. Sure, but this doesn't make it any more secure. I only know very little about Authentica, but it also doesn't strike my fancy. Private keys are private, period. There got to be other ways to make PK cryptography easier. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
At 05:42 PM 7/8/2003, Thor Lancelot Simon wrote: I believe the Certicom library is somewhere around there in size, and it is a pretty extensive implementation. Costs money though. ;-) IIRC, the embedded SSL library I wrote (with Chris Hawk) at Certicom was < 64K of 68K code (we originally wrote it for PalmOS devices), including all crypto, for a fully-compliant SSL 3.0 & X.509v3 implementation (client-side SSL only, with a profiled subset of SSL ciphersuites and X.509 features, of course). And it could run with a RAM usage of substantially less than 10K/connection. And we wrote it in less than a month (it was our third or fourth time implementing SSL and X.509, though). The complete Certicom library is somewhat bigger, but it's got a lot of flexibility, (modular crypto interface, etc.), and code size wasn't a concern on desktop/server platforms. - Tim - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
> One difference is that with the identity-based crypto, once a sender > has acquired the software and the CA's public key, he doesn't have to > contact the CA to get anyone's "certificate". He can encrypt to anyone > without having to contact the CA, just based on the email address. > Your proposed substitute doesn't allow for this. But you don't have to contact the CA to get someone's certificate. A standard way is to send them an email saying "can you send me a signed message?" This also ensures you have the right public key. I haven't studied the details of IBE, but I assume that (a) there may be multiple IBE-based "CA"s, with different parameters, and (b) the identity that's used to encrypt will be not just a name, but a name and a date (to ensure that some revocation-like capability exists). In either case, you can't simply pick the email address and use it as the public key; you need to establish some additional information first. This seems to put us back in the same place as with standard PKI, usability-wise. (Or, rather, there may be a usability delta for IBE, but it's very small). When you add to this the fact that the server knows your decryption key... I really don't see why this is worth getting excited about commercially, or even from an engineering perspective. It's cool maths, though. Cheers, William - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
At 05:30 PM 7/8/2003, Nomen Nescio wrote: One difference is that with the identity-based crypto, once a sender has acquired the software and the CA's public key, he doesn't have to contact the CA to get anyone's "certificate". He can encrypt to anyone without having to contact the CA, just based on the email address. Your proposed substitute doesn't allow for this. True, but how valuable is that, given that you can't send the actual message without contacting a server? I suppose one can construct theoretical scenarios where that's a benefit, but it seems to be a pretty narrow niche to me. > but you don't need goofy new crypto to accomplish it. The Weil pairing hardly constitutes "goofy new crypto". They are doing all kinds of cool stuff with pairings these days, including privacy-enhancing technology such as public keys with built-in forward secrecy. I retract the "goofy". My point was that the market is incredibly reluctant to adopt new technology: if you can solve a problem with components known to the marketplace, you're much more likely to be successful than if you invent something new. This is above and beyond any reluctance to adopt new cryptographic technology based on concerns about security. Even if the Weil pairing is known to be 100% secure and tested, any new solution has to, as a practical matter, leap a huge hurdle to overcome available, well known alternatives. I've spent years attempting to get the market to accept alternative security solutions, and I can testify to how high that hurdle is. In my opinion, identity-based cryptography has insufficient upside to overcome that hurdle, especially given that it is not without its downsides (escrowed private keys, no protection against key compromise). - Tim - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 02:20:46PM -0700, Eric Murray wrote: > > For comparison purposes, I have a copy of an SSLv3/TLS client library > I wrote in 1997. It's 56k of (Intel Linux) code for everything > except RSA. That includes the ASN.1 and X.509 parser. > Implementing the server-specific parts would add only another > couple k. This was done for a handheld computer but runs on > unix as well. I believe the Certicom library is somewhere around there in size, and it is a pretty extensive implementation. Costs money though. ;-) > OpenSSL is huge because it's also a general purpose crypto lib, supports > a bunch of hardware and a bunch of algorithms, SSLv2 (ew), old apis, > non-blocking, etc etc. It's also hideously overabstracted. That, to my mind, is why it's both hard to use and hard to maintain. Unfortunately, its "API" is the only one that is in wide use on Unix systems, which means that any alternative would probably be forced to duplicate a frightening amount of OpenSSL's internal complexity in order to present its _external_ complexity. Thor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Voltage - Identity Based Encryption.
also sprach C. Wegrzyn <[EMAIL PROTECTED]> [2003.07.08.2324 +0200]: > This is the same approach used in the Authentica system but it is > deployed in an enterprise environment. Sure, but this doesn't make it any more secure. I only know very little about Authentica, but it also doesn't strike my fancy. Private keys are private, period. There got to be other ways to make PK cryptography easier. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] invalid PGP subkeys? use subkeys.pgp.net as keyserver! "die menschen drängen sich zum lichte, nicht um besser zu sehen, sondern um besser zu glänzen." - friedrich nietzsche pgp0.pgp Description: PGP signature
Re: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
Tim Dierks writes: > I don't think it's an interesting solution. I don't see any interesting > application that's possible with this system which you couldn't do with > existing public-key cryptography: for example, I could write a protocol & > software where you could request a public key from a server for any e-mail > address; if the user didn't already have an enrolled key, my trusted server > would generate one and enroll it on their behalf. When they got an > encrypted message, they could contact me, authenticate themselves, and I'd > send them their secret key. One difference is that with the identity-based crypto, once a sender has acquired the software and the CA's public key, he doesn't have to contact the CA to get anyone's "certificate". He can encrypt to anyone without having to contact the CA, just based on the email address. Your proposed substitute doesn't allow for this. > but you don't need goofy new crypto to accomplish it. The Weil pairing hardly constitutes "goofy new crypto". They are doing all kinds of cool stuff with pairings these days, including privacy-enhancing technology such as public keys with built-in forward secrecy. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Voltage - Identity Based Encryption.
This is the same approach used in the Authentica system but it is deployed in an enterprise environment. Chuck Wegrzyn martin f krafft wrote: also sprach Hack Hawk <[EMAIL PROTECTED]> [2003.07.08.0154 +0200]: So what they're saying is that your PRIVATE key is stored on a server somewhere on the Internet?!?! I believe it says it is generated upon initial request, but this is about as bad. I fully agree with you, this sounds fishy. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 04:32:41PM -0400, Thor Lancelot Simon wrote: > I trimmed OpenSSL down to just TLSv1 and only the FIPS-140 conformant > algorithms for a FIPS-140 conformance project at ReefEdge (and yes, [..] > The result was still several hundred kilobytes -- actually, I don't > have exact numbers handy but I believe it was more than a megabyte > in size. OpenSSL is not the TLS implementation I would use if I had > any other free option that offered reasonable performance. :-( For comparison purposes, I have a copy of an SSLv3/TLS client library I wrote in 1997. It's 56k of (Intel Linux) code for everything except RSA. That includes the ASN.1 and X.509 parser. Implementing the server-specific parts would add only another couple k. This was done for a handheld computer but runs on unix as well. OpenSSL is huge because it's also a general purpose crypto lib, supports a bunch of hardware and a bunch of algorithms, SSLv2 (ew), old apis, non-blocking, etc etc. Eric - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Voltage - Identity Based Encryption.
also sprach Hack Hawk <[EMAIL PROTECTED]> [2003.07.08.0154 +0200]: > So what they're saying is that your PRIVATE key is stored on > a server somewhere on the Internet?!?! I believe it says it is generated upon initial request, but this is about as bad. I fully agree with you, this sounds fishy. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] invalid PGP subkeys? use subkeys.pgp.net as keyserver! "i never travel without my diary. one should always have something sensational to read on the train." -- oscar wilde pgp0.pgp Description: PGP signature
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 09:18:53PM +0100, M Taylor wrote: > On Tue, Jul 08, 2003 at 12:19:54PM -0700, Eric Rescorla wrote: > > > > As I said before, the problem here isn't SSL. Rather, it's the way > > that OpenSSL does things. Now, it would be a real contribution for > > you to write a simple wrapper for OpenSSL. I've seen people do stuff > > like that, but it's generally too custom for general use. > > stunnel (www.stunnel.org), which is an "universial SSL wrapper". > > So perhaps Tom could could write a EZ-OpenSSL wrapper, which remove > legacy options (disable SSLv2 and SSLv3, just TLSv1), limit algorithm > choice to sensible defaults, and ensure the programmer has as decent > as available random numbers. The problem isn't just the interface that OpenSSL presents to the application programmer (which is lousy, and which in a lot of cases is totally undocumented; it also has the "Kerberos problem" which is to say that to do cryptographically necessary things it is often necessary to use internal or deprecated functions directly, and these change from release to release... ugh!) it's also how it's implemented. I trimmed OpenSSL down to just TLSv1 and only the FIPS-140 conformant algorithms for a FIPS-140 conformance project at ReefEdge (and yes, we did then have that version of OpenSSL tested and certified, but no, you can't have it for free ;-)). It was not so hard, but it was immensely time-consuming and I had to learn a totally unreasonable amount about OpenSSL's internals to actually ensure that all the nonconformant algorithms were disabled (in some cases it would have been impractical to not build them at all, unfortunately). The result was still several hundred kilobytes -- actually, I don't have exact numbers handy but I believe it was more than a megabyte in size. OpenSSL is not the TLS implementation I would use if I had any other free option that offered reasonable performance. :-( Thor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 11:53:13AM -0700, Eric Rescorla wrote:
> Ian Grigg <[EMAIL PROTECTED]> writes:
>
> > It's not just you. The field seems to be evenly
> > divided between those who view SSL as a mess, and
> > those who view it as the only sane choice because
> > so much attention has been put on it.
> I'm not sure why you think that these two views are
> inconsistent. Sure, SSL embodies lots of mistakes, and I'm hard on
> some of those in my book. However, my experience is that when people
> sit down and try to do a better job, they generally bungle it. Tom's
> attempt is only the latest example.
Attempts to do new stuff should not be discouraged.
But like home-made ciphers, they should be viewed as interesting
learning exercises rather than serious secure protocols.
> > The main thing that reduces SSL's applicability to
> > real world problems come down to the assumption of
> > certificates as part and parcel of the security
> > model.
> This is just wrong. There are extensions to SSL to support Kerberos,
> SRP, and even primitive shared keys (see Peter Gutmann's latest draft
> on this topic).
Unauthenticated Diffie-Hellman has been in SSLv3 since the beginning.
Rejecting SSL because it "uses certifictes" is either a result
of ignorance of the spec or an excuse for re-inventing.
> > It's definately not just you - but one of the reasons
> > that it feels like that is that the SSL supporters
> > tend to protect their franchise very aggresively.
> It's not just SSL. I've beaten up on people who were trying to
> reinvent S/MIME in this very forum. It's just that people seem to try
> to reinvent SSL about 5 times more often than they try to reinvent
> anything else. My guess is that that's because the channel security
> problem *looks* so simple and so it seems like it should be easy to do
> something simpler and better than SSL.
If you are into wheels, it's more fun to (re-)invent the wheel the wheel
than it is to use the existing wheels laying about. The posters here
are wheel geeks ("look, I can build a 12-spoke wheel!") who are not
interested in the reliabilty of the bicycles that the wheels are used on.
> > Nonsense. We aren't even up to being the C-team,
> > we don't make the team. And we won't ever until
> > we cast off the shackles of rote acceptance, and
> > start challenging SSL on its inadequacies.
If you start with the same assumptions you will wind up
with something that looks very similar to SSL. Once you have discovered
and addressed all the same holes and pitfalls that is.
While it's a fun learning exercise, it's not useful to the rest of
the world... SSL, because it has had more review than your protocol
will ever get, will be more secure.
The only way to end up with something significantly different
is to address a different set of requirements... and more different
than "no certificates".
A good place to start is Eric's _SSL and TLS_ book.
How can you make something better without understanding the mistakes
of the past?
Eric
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 12:19:54PM -0700, Eric Rescorla wrote: > tom st denis <[EMAIL PROTECTED]> writes: > > > > My logic is that if you're going to create something new, it should > > > be better than what already exists. There is precious little > > > evidence that libtomnet fills that bill. > > > > LibTomNet has eight functions and one data type in the API. To a > > complete stranger that is a nice welcome change than say all the > > constants, functions, structures in SSL. > > As I said before, the problem here isn't SSL. Rather, it's the way > that OpenSSL does things. Now, it would be a real contribution for > you to write a simple wrapper for OpenSSL. I've seen people do stuff > like that, but it's generally too custom for general use. stunnel (www.stunnel.org), which is an "universial SSL wrapper". So perhaps Tom could could write a EZ-OpenSSL wrapper, which remove legacy options (disable SSLv2 and SSLv3, just TLSv1), limit algorithm choice to sensible defaults, and ensure the programmer has as decent as available random numbers. Or rewrite LibTomNet to match the basic PROTOCOL concepts of TLS, without the legacy compatability, and reduce/remove algorithm negotation, etc. No need to actually be compatible with TLS, just to use the same protocol concetps. Until Tom's libtomnet known/tested is secure from all known attacks on SSL/TLS, he should refrain from calling it 'secure' since he cannot be reasonable certain that it is in fact secure. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Re: Encrypted Virtual Drives
Or you can run vmware under XP, run NetBSD under vmware, use CGD, and export it back to windows with samba. It's sick, but I know of at least one person who is doing this, and he says the performance is acceptable (on his 1+ GHz laptop). /ji - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis <[EMAIL PROTECTED]> writes: > --- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > tom st denis <[EMAIL PROTECTED]> writes: > > > The point I'm trying to make is that just because a fairly standard > > > product exists doesn't mean diversity is a bad thing. Yes, people > > may > > > fail to create divergent products but that isn't a bad thing. You > > > learn from the faults and create a better product. I mean by your > > > logic we would all drive Model T cars since well... diversity is > > bad. > > > The model T exists! > > My logic is that if you're going to create something new, it should > > be better than what already exists. There is precious little > > evidence that libtomnet fills that bill. > > To you. You know SSL inside and out. > > LibTomNet has eight functions and one data type in the API. To a > complete stranger that is a nice welcome change than say all the > constants, functions, structures in SSL. As I said before, the problem here isn't SSL. Rather, it's the way that OpenSSL does things. Now, it would be a real contribution for you to write a simple wrapper for OpenSSL. I've seen people do stuff like that, but it's generally too custom for general use. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: basic question: semantics of "map", "tie", etc in PKI
At 11:40 AM 7/8/03 -0600, Anne & Lynn Wheeler wrote:
>A hardware token that requires a PIN/password to operate can be considered
>two-factor authentication ("something you have" and "something you know").
I was going to comment on how a simple plastic debit card
that includes a photo provides the third "something you are".
(More reliably than the signature, which is also "something
you are", but readily forged/ignored.)
Then it occurred to me: as cameras become ubiquitous
(e.g., in cell phones) some extra security could be obtained
by sending a trusted photo of the account holder plus a live picture
of the card user.
A picture glued into the card could be forged, but a
smartcard (with more data area than a magstripe)
could include a picture of the account holder,
so a thief has no idea what to look like. But the vendor can
check the encrypted smartcard face to the face on the phone
or webcam. For high-value remote transactions, this might
be viable in a few years.
This is already standard practice
on high-security building-entry cards (and passports?),
with the guard comparing the card-embedded face to the one before him.
Ubiquitous cameras will bring that to remote transactions,
reducing cost due to lower fraud.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
Ian Grigg <[EMAIL PROTECTED]> writes: > tom st denis wrote: > > > > --- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > > [Standard rant follows... :)] > > > I'm trying to figure out why this is a good idea even in principle. > > > > Maybe its just me but SSL is overly complicated. > > It's not just you. The field seems to be evenly > divided between those who view SSL as a mess, and > those who view it as the only sane choice because > so much attention has been put on it. I'm not sure why you think that these two views are inconsistent. Sure, SSL embodies lots of mistakes, and I'm hard on some of those in my book. However, my experience is that when people sit down and try to do a better job, they generally bungle it. Tom's attempt is only the latest example. > The main thing that reduces SSL's applicability to > real world problems come down to the assumption of > certificates as part and parcel of the security > model. This is just wrong. There are extensions to SSL to support Kerberos, SRP, and even primitive shared keys (see Peter Gutmann's latest draft on this topic). > It's definately not just you - but one of the reasons > that it feels like that is that the SSL supporters > tend to protect their franchise very aggresively. It's not just SSL. I've beaten up on people who were trying to reinvent S/MIME in this very forum. It's just that people seem to try to reinvent SSL about 5 times more often than they try to reinvent anything else. My guess is that that's because the channel security problem *looks* so simple and so it seems like it should be easy to do something simpler and better than SSL. Incidentally, I suspect that this is what was going through Hickman's head when he designed SSLv2, which is no doubt why it's such a botch. > Which is a total crock. If SSL can't make up its > credibility in the open market place, then it isn't > worth idolising. Are you on crack? SSL HAS won in the market place. It's only the amateurs who persist on trying to reinvent it. > Nonsense. We aren't even up to being the C-team, > we don't make the team. And we won't ever until > we cast off the shackles of rote acceptance, and > start challenging SSL on its inadequacies. > > Tom, you are not alone! Dabble on! You know, Ian, this argument would be a lot more convincing if the people who tried to reinvent SSL didn't always botch the job. I've yet to see one of these things that didn't have glaring flaws that wouldn't have been made by someone who had taken the time to really understand SSL. No doubt that's because once you've spent some time thinking about the problem you get driven to roughly the same set of design decisions SSL embodies. This isn't because the SSL authors were such geniuses, but rather because there's basically one best way to do things. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis wrote: > > --- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > [Standard rant follows... :)] > > I'm trying to figure out why this is a good idea even in principle. > > Maybe its just me but SSL is overly complicated. It's not just you. The field seems to be evenly divided between those who view SSL as a mess, and those who view it as the only sane choice because so much attention has been put on it. (That's just my seat of the pants feel for it, in gauging the public and private responses to the series of rants on SSL I've written. And it isn't just a recent development, I've known other far more competent (than me) cryptoplumbers who were dissatisfied with SSL, going back as far as 1997.) Using SSL as a base for a new set of requirements seems to be about as complicated as a competant cryptoplumber doing his own. Obviously, SSL will give you a jumpstart in security over your homegrown crypto, but less obviously, the complications and misturns built into SSL make tuning it to your application a much harder task, and achieving a unified security model is difficult because it's not a simple starting point. The main thing that reduces SSL's applicability to real world problems come down to the assumption of certificates as part and parcel of the security model. Also, the threat model is unrealistic, and the consequent security properties seem more to derive from "what we can do" rather than "this is what your application demands and needs." It's definately not just you - but one of the reasons that it feels like that is that the SSL supporters tend to protect their franchise very aggresively. Which is odd, really, I haven't myself worked out why the supporters of a particular protocol are so adamant that one should not experiment in a field as complicated and challenging as crypto. Their attitude is religious, it is tantamount to saying that you shouldn't dare to assault the ivory tower. SSL is the officially sanctioned way of doing Internet crypto. Capice? Which is a total crock. If SSL can't make up its credibility in the open market place, then it isn't worth idolising. If you looked at it - and you say you did - and concluded you could do better on your own, then more power to you. And us all. An entire generation of crypto engineers have been fed this notion that they needn't bother with their own, which has had the net result of reducing crypto knowledge, reducing security, and leaving the net reliant on an infrastructure that just can't meet its own needs, let alone the needs of users. Somebody said we were the A-team. John Gilmore, I think, but that's from memory. Nonsense. We aren't even up to being the C-team, we don't make the team. And we won't ever until we cast off the shackles of rote acceptance, and start challenging SSL on its inadequacies. Tom, you are not alone! Dabble on! -- iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: basic question: semantics of "map", "tie", etc in PKI
At 08:45 AM 7/8/2003 -0700, Fritz Schneider wrote:
This is possibly a silly question, but here goes.
Reading something PKI-related the other day I was wondering about
the semantics of different kinds of certificates. One usually says that
traditional id certs "map names to keys" or "tie keys to names"[1]. This
is usually written:
name -> key
Other certs have similar semantics (they "map" and "tie"). For example,
in order to achieve authorization one could keep an ACL which "maps
permissions to names" ("ties names to permissions"):
permission -> name
Given these two mappings its then possible to get the mapping:
permission -> name -> key
which authorizes the key for the permission.
I actually have two questions.
The first is what exactly does "mapping" mean in this sense? I'm
not sure that it means "mapping" in the sense of the algebraic definition
because for each x that is mapped, there should only be only one value to
which x is mapped, and I think of an ACL or SPKI cert as incompatible with
this notion. "Tie" and "bind" seemed to be used in to indicate both a
mapping or that something is mapped to.
My second question is, in mappings like:
permission -> name -> key
why do we think of it as mapping permission to a key and not the other way
around? The way I typically think about the task of reasoning about
authorization seems to work in the opposite direction.
-- fritz
[1] RFC2693, for example
basic authentication taxonomy is something like:
1) something you have (like a hardware token)
2) something you know (like a pin/password)
3) something you are (like biometrics)
frequently PKIs talk about certifying (aka CA's are certification
authorities, certificates represent some certification by a certification
authority) some binding between something and a public key.
one could claim that the choice of vocabulary was trying to elevate
something from straight-forward authentication to something like
identification and non-repudiation ... which would represent much more
value and therefor the public key owner buying the certificate might pay
more. Note, however, identification and non-repudiation is primarily of
benefit to the relying-party that receives the certificate but the
standard TTP business model has the private key owner paying for the
certificate (not the relying party which is receiving the primary
benefit).
There has been lots of discussion that PKIs don't actually do
identification or non-repudiation which requires lots of additional processes.
Certification authorities basically have an entity prove that it can
generate a digital signature that can be validated with the supplied public
key . basically a form of "something you have" authentication ... the
entity can prove it has the private key. The certification authority then
validates some other piece of information (like the entity's email
address); stores the public key and the certified information in a database
and then creates a credential/certificate as to the binding between the
certified information and the certified public key.
Originally, x.509 specification was thought of as heavily overloading a
certificate with lots of identity related information as well as
privilege/permission related information ... "bound" to a public key in a
certificate. It pretty quickly became apparent that a
credential/certificate heavily overloaded with identity and permission
information and indiscriminately broadcast all over the world created
enormous privacy problems.
Financial institutions in the mid-90s dropped back to relying-party-only
certificates which basically contain only account number and the public key
because of the enormous privacy and liability problems. However, a standard
business process involving certificate has the key-owner 1) creating a
transaction/message, 2) appending a digital signature, 3) appending the
certificate ... and transmit the "triple" to the bank.
The bank extracts the account number from the transaction/message, reads
the account record and validates the digital signature using the public key
stored in the account record. The relying-party-only certificate containing
only an account number and public key (because of the enormous liability
and privacy issues) is never used. It was subsequently observed that such
relying-party-only certificates were redundant and superfluous.
The original purpose of certificates were to provide various certified
associations for an offline world (something analogous to letters-of-credit
from the days of sailing ships). These certificates were a
stand-in/substitute for situations where it was not possible to directly
access the real information. Most of them are quickly loosing any reason
for existence given the extensive proliferation of internet and wireless
technologies around the world. It is becoming more and more unlikely that
there wouldn't be some form
Re: Encrypted Virtual Drives
I've been using BestCrypt from Jetico for some years. They're Finnish. I haven't tried it with XP but the new version works with it. If you don't have a license, the container goes "read only" so you don't lose your data. I haven't vetted them for technical or political trustworthyness because my threat model doesn't require maximum protection. http://www.jetico.com/ I haven't encountered major usage problems over the years. Use at your own risk. DCF - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
I think Eric has done a slam-dunk, and perhaps our moderator will close this thread of dicussion. :) Eric's cursory examination has shown that Tom's code has a number of security flaws (that can be fixed) and weaknesses (that are apparently deliberate), in code that's not much smaller than SSL, and is certainly less feature-ful. Congrats on the learning exercise, Tom. Regretablly the big lesson has avoided you so far. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
basic question: semantics of "map", "tie", etc in PKI
This is possibly a silly question, but here goes.
Reading something PKI-related the other day I was wondering about
the semantics of different kinds of certificates. One usually says that
traditional id certs "map names to keys" or "tie keys to names"[1]. This
is usually written:
name -> key
Other certs have similar semantics (they "map" and "tie"). For example,
in order to achieve authorization one could keep an ACL which "maps
permissions to names" ("ties names to permissions"):
permission -> name
Given these two mappings its then possible to get the mapping:
permission -> name -> key
which authorizes the key for the permission.
I actually have two questions.
The first is what exactly does "mapping" mean in this sense? I'm
not sure that it means "mapping" in the sense of the algebraic definition
because for each x that is mapped, there should only be only one value to
which x is mapped, and I think of an ACL or SPKI cert as incompatible with
this notion. "Tie" and "bind" seemed to be used in to indicate both a
mapping or that something is mapped to.
My second question is, in mappings like:
permission -> name -> key
why do we think of it as mapping permission to a key and not the other way
around? The way I typically think about the task of reasoning about
authorization seems to work in the opposite direction.
-- fritz
[1] RFC2693, for example
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
[Publicity-list] CFP: DIMACS Workshop on Large-Scale Internet Attacks
* Call for Participation DIMACS Workshop on Large-Scale Internet Attacks September 23 - 24, 2003 DIMACS Center, Rutgers University, Piscataway, NJ Organizers: Vern Paxson, ICSI, [EMAIL PROTECTED] Steve Bellovin, AT&T Research, [EMAIL PROTECTED] Stuart Stanford, Silicon Defense Stefan Savage, University of California, [EMAIL PROTECTED] Presented under the auspices of the Special Focus on Communication Security and Information Privacy. As the Internet has grown greatly in size, new forms of attacks that leverage the network's increasing scale have gained prominence. At the same time, the network's scale also often increases the difficulty of countering attacks, making it more difficult to trace back attackers or deploy widespread defensive measures. This workshop aims to assess the lay of the land in terms of large-scale Internet attacks and then to look for principles common to the problem domain. The focus will be on three general types of large-scale attacks: distributed denial-of-service (DDOS), self-propagating malicious code (worms), and attacks targetting the network's components (infrastructure attacks). Participation in the workshop is quite limited because of the emphasis on achieving a high degree of interactivity & discussion. Potential attendees interested in participating should contact the organization chair at [EMAIL PROTECTED], including a description of relevant background and the specific topic(s) of interest for discussion & exploration. Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/Attacks/ **PLEASE BE SURE TO PRE-REGISTER EARLY** - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
At 18:31 07/07/2003 -0400, Tim Dierks wrote: ... So, it all boils down to a system that's not dissimilar to a traditional CA-based public key system. In order for you to participate, you go to the trusted third party, they verify that you own the e-mail address you're claiming to possess (with whatever level of verification they insist upon), and if you do, they generate your secret key for you and send it to you. You can now decrypt messages which other people encrypt with that public key. I don't think it's an interesting solution. I don't see any interesting application that's possible with this system which you couldn't do with existing public-key cryptography: for example, I could write a protocol & software where you could request a public key ... Tim: wonderful concise summary and I couldn't agree more. Thanks for taking the time to explain so nicely why this kind of systems, while cute, are not really helping applied cryptography (IMHO). Best regards... Amir Herzberg http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Encrypted Virtual Drives
Hi, Could anyone offer any thoughts on what is the "best" encrypted virtual disk drive, which can run on (at least) Windows XP Pro. I used to use the free version of PGPdisk (which you get with PGP version 6.0.2i), but that won't work with Windows XP. I also used to use ScramDisk, but that also won't work with Windows XP. I have been using new version of PGPdisk (PGP version 8.0), but there are a number of problems with that: being (1) the license ($50) seems to be enforced per-computer, not per-user, so if you upgrade from one computer to another you either have to pay again or plead your case with the PGP Corporation's support centre (which is only open during office hours Monday to Friday, so don't try this during the weekend), and (2) their web site had some problem last weekend such that it wouldn't actually let me buy a new license even though I was prepared to pay for it, and (3) the format of the container volume is totally incompatible with that of PGP 6.0.2i. These problems combined mean that if your computer totally dies, to get your data back (assuming the existence of a backup) you are reliant on a single company to grant you a new license to get the software working, and getting that licence is not necessarily easy. I have also tried the new version of DriveCrypt (the successor to ScramDisk) ... but I worry about this because the company who make this (Securstar) no longer provide source code. I'd kind of like to write my own, but doing the crypto is just the easy part - the hard part is actually writing a virtual drive - I can't find any tutorials on that part. So I put it to this list, what do folk here reccommend? Jill
Re: LibTomNet [v0.01]
tom st denis <[EMAIL PROTECTED]> writes: > --- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > > > Heck, if you could find a security flaw in LibTomNet [v0.03] I'll > > buy > > > you a beer. > > Your protocol does not use appear to have any protection against > > active attacks on message sequence, including message deletion, > > replay, etc. True, the attacker can't inject *predictable* > > plaintext, > > but he can inject garbage plaintext and have it accepted as real. > > No he can't. You need a correct HMAC for the data to be accepted. > This allows a replay attack which I should fix. One beer. > > Ultimately though the plaintext won't match if you replay though so its > only half a bug [though a bug that must be fixed]. Uh, this is exactly what I said. If you delete messages or replay them, they will pass through the HMAC and be decrypted (thus giving you unpredictable garbage) and passed to the application layer. > > Your protocol is susceptible to truncation attack via TCP FIN > > forging. > > I don't even know what that is but my protcol must read an entire block > before parsing it. Yes, but if I forge a TCP FIN in between blocks, you can generate a fake connection close. This is a problem if the protocol layered over top uses connection close to indicate end of data as (say) HTTP does. That's why SSLv3 and above include a close_notify message in the alerts. > > Your server doesn't generate any random values as part of the > > handshake, > > thus, leaving you open to full-session replay attack. > > Which is why people should use some authentication scheme ontop of > this. Note that the server has no clue who you are after making the > connection. This is intentional.\ This doesn't always help, unfortunately. Consider the case where you're using a replayable authentication scheme such as passwords over your encrypted session. This is perfectly natural and people do it with SSL all the time. So, the attacker captures you doing some transaction replays it to the server. Congratulations, you've now done it twice. The standard procedure to prevent this (used in SSL, IKE, etc.) is for the server to send the client a nonce in his hello message, thus preventing client-side replay. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
--- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > Heck, if you could find a security flaw in LibTomNet [v0.03] I'll > buy > > you a beer. > Your protocol does not use appear to have any protection against > active attacks on message sequence, including message deletion, > replay, etc. True, the attacker can't inject *predictable* > plaintext, > but he can inject garbage plaintext and have it accepted as real. No he can't. You need a correct HMAC for the data to be accepted. This allows a replay attack which I should fix. One beer. Ultimately though the plaintext won't match if you replay though so its only half a bug [though a bug that must be fixed]. > Your protocol is susceptible to truncation attack via TCP FIN > forging. I don't even know what that is but my protcol must read an entire block before parsing it. > Your server doesn't generate any random values as part of the > handshake, > thus, leaving you open to full-session replay attack. Which is why people should use some authentication scheme ontop of this. Note that the server has no clue who you are after making the connection. This is intentional.\ So if you are in the area [or at Crypto'03] I'll buy you a beer. Tom __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis <[EMAIL PROTECTED]> writes: > --- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > In other words, this is just an exercise in Not Invented Here. > > Wonderful. > > Oh, ok so I need your permission? No, you don't need my permission. You can do any fool thing you want. It would just be nice if you were spending effort filling some actual need, rather than reinventing the wheel. > Who gave Netscape permission to > write SSL? [or whoever invented it] Netscape. However, the situation was different then. There was actually a market niche that SSL didn't fill. It has yet to be established that LibTomCrypt is in that position. > Generally I agree that homebrew crypto is a bad idea but I think you > are undervaluing my knowledge in the field. I'm not some two-bit IT > specialist trying to make a quick buck. You don't seem to understand the issue. It has nothing to do with how competent you are and everything to do with the fact that people make mistakes and so homebrew stuff is bad when you can avoid it. Everyone I know who has worked in this field has made a bunch of mistakes and depends on others to catch them. > My library *really* only has eight functions, it *really* is only 13KB > [excluding the crypto], it *really* provides secure sockets. And I claim that SSL implementations can be gotten down to very nearly that size, especially if you're willing to compromise a lot of the features, so what virtue is your library providing? > Just because it isn't SSL doesn't mean its incapable of being secure. No, it just means that it's never going to get the kind of security analysis that SSL has, which means that there are probably a bunch of undiscovered holes. > > Moreover, your original message said that you intended to use > > SSL, but as you yourself admit, you don't understand it and yet > > you feel comfortable holding forth about it's merits compared > > to your brand new protocol. Huh? > > Yeah, because I'm not going to sit and study 67 pages for more than a > day to figure out how to send a key or perform key exchange. It turns out that doing a principled job is a lot more complicated than doing key exchange. That's one of the things that one discovers when actually writing a full protocol rather than just whipping something together. > To sum up, I do agree that homebrew stuff is generally of lower quality > than peer-reviewed standards but I think you're too easily dismissing > all other works because they're not your own. To that end I call you > an elitist pig. Seeing as I didn't write SSL, I'm just the document editor, that just makes you look silly. > Heck, if you could find a security flaw in LibTomNet [v0.03] I'll buy > you a beer. Your protocol does not use appear to have any protection against active attacks on message sequence, including message deletion, replay, etc. True, the attacker can't inject *predictable* plaintext, but he can inject garbage plaintext and have it accepted as real. Your protocol is susceptible to truncation attack via TCP FIN forging. Your server doesn't generate any random values as part of the handshake, thus, leaving you open to full-session replay attack. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Voltage - Identity Based Encryption.
So what they're saying is that your PRIVATE key is stored on a server somewhere on the Internet?!?! http://www.voltage.com/technology/ibe.htm According to the description, authentication is obtained using a directory or a domain. If using a Microsoft domain for authentication is required, then how is it that the receiver is NOT required to obtain/purchase the software? Here's the quote. http://www.msnbc.com/news/935795.asp?0dm=T16KT "Krishnamurthy said only the sender of an encrypted e-mail needs to have the company's software. The recipient can then automatically decode the message while using Outlook, Outlook Express, Eudora, or even a BlackBerry handheld." - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis <[EMAIL PROTECTED]> writes: > --- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > tom st denis <[EMAIL PROTECTED]> writes: > > > Two weeks ago I sat down to learn how to code my own SSL lib [key > > on > > > being small]. Suffice it to say after reading the 67 page RFC for > > SSL > > > 3.0 I have no clue whatsoever how to implement SSL. > > Funny, none of the 30 or so other people who have done SSL > > implementations had any problem. > > Arrg whatever. I really don't give a hoot what you think. > > What I don't get is you guys who are presumably a smart bunch can't > figure out that > > I > > AM > > NOT > > TRYING > > TO > > REPLACE > > SSL. > > I'm just writing a simple library to provide secure sockets. That's > it, that's all. In other words, this is just an exercise in Not Invented Here. Wonderful. > Believe it or not, this may come as a surprise to you, but not everyone > requires standsrd compliant protocols. If the past 20 years of security work have taught us anything, it's the value of standardized tools that get a lot of review so that we can be confident that they're not totally hosed. When people go off and invent their own stuff without good reason, that's not good security practice. That's fine if they're just screwing around, but when they come up with all sorts of bogus reasons why people might want to use their homegrown stuff instead of the standard stuff, that's not so fine. Moreover, your original message said that you intended to use SSL, but as you yourself admit, you don't understand it and yet you feel comfortable holding forth about it's merits compared to your brand new protocol. Huh? -Ekr P.S. You claimed earlier that you didn't think RFC 2246 was clear enough to write a complaint implementation. I was sincere in asking what you find underspecified. It's my job to make it as complete as possible. -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis <[EMAIL PROTECTED]> writes: > Two weeks ago I sat down to learn how to code my own SSL lib [key on > being small]. Suffice it to say after reading the 67 page RFC for SSL > 3.0 I have no clue whatsoever how to implement SSL. Funny, none of the 30 or so other people who have done SSL implementations had any problem. > The RFC looks like it was written by a member of the ACLU and done at > an hourly rate of some sort. It contains no test vectors, no sample > source code and generally is not enough information to code a compliant > SSL protocol. I'd be interested to know in what way you believe the TLS RFC is not sufficient to write a complaint implementation. Except for some edge cases, it's fully specified as far as I know. Anyway, I'm the document editor so it's my job to fix it. This isn't an invitation to complain more about the writing quality (for which I'm not responsible in any case). But if you think that there's actually something that's unspecified, I want to know about that. As for the complexity of TLS, that's what happens when you design a general protocol. I can pretty much guarantee you that every part of TLS has been used by someone at one time or anotehr. > My 64KB demo includes the server, the client, all the crypto [including > a full RSA implementation] and the LibTomNet protocol. I could make > the demo smaller by manually trimming LibTomCrypt. And we got SSLv2 and v3 in <100 kb without trying particularly hard, using BSAFE, which is enormous. This isn't much of an argument, really. > Not only is my code way smaller than a compliant SSL library but it is > also simpler. There are only eight functions in LibTomNet and of > LibTomCrypt you only need a half dozen at most [setup the prng, RSA key > gen, export/import]. In otherwards my code is [should be] very easy to > work with since there is a minimum of clutter to get in the way. > > I mean just download a copy [v0.03 is the latest] and check out the > demo [demos/ex1.c]! > > At anyrate LibTomNet is not an SSL replacement. It's a library for > developers who need simple to work with secure sockets. This striked me as quite confused. What makes developer's lives simple is simple APIs, not simple implementations. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
--- Eric Rescorla <[EMAIL PROTECTED]> wrote: > [Standard rant follows... :)] > I'm trying to figure out why this is a good idea even in principle. Maybe its just me but SSL is overly complicated. I've been dabbling with crypto since I was sixteen. I've written several popular libs already [LibTomCrypt and LibTomMath] so while I'm not a PhD in crypto I think I'm fairly competent enough to sit down and implement an algorithm per specs [to a limit]. Two weeks ago I sat down to learn how to code my own SSL lib [key on being small]. Suffice it to say after reading the 67 page RFC for SSL 3.0 I have no clue whatsoever how to implement SSL. The RFC looks like it was written by a member of the ACLU and done at an hourly rate of some sort. It contains no test vectors, no sample source code and generally is not enough information to code a compliant SSL protocol. So I wrote LibTomNet. It provides exactly what I wanted and is very simple to understand and work with. > I've seen <100k SSL implementations and that included the ASN.1 > processing for certs. I would imagine that one could do a compliant > SSL implementation that used fixed RSA keys in roughly the same > code size as your stuff. My 64KB demo includes the server, the client, all the crypto [including a full RSA implementation] and the LibTomNet protocol. I could make the demo smaller by manually trimming LibTomCrypt. Not only is my code way smaller than a compliant SSL library but it is also simpler. There are only eight functions in LibTomNet and of LibTomCrypt you only need a half dozen at most [setup the prng, RSA key gen, export/import]. In otherwards my code is [should be] very easy to work with since there is a minimum of clutter to get in the way. I mean just download a copy [v0.03 is the latest] and check out the demo [demos/ex1.c]! At anyrate LibTomNet is not an SSL replacement. It's a library for developers who need simple to work with secure sockets. Tom __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis <[EMAIL PROTECTED]> writes: > The lib uses RSA for key exchange [and the client may scrutinize the > key before making the connection via a callback], AES-128-CTR [two > different keys for each direction] and SHA1-HMAC. The niche of the lib > is that my library compiles to a mere 10KB. Add SHA1, AES, HMAC, RSA > and LTM and you get 60KB demo apps Ideally you should build LTC > without mpi.o and link against both LTC and LTM. > > The lib does not implement any other protocol like SSH/SSL/TLS [etc]. > > I have to mention this in good conscience. I ==>STRONGLY<== DISCOURAGE > people from using this library in fielded systems. I've only been > working on it for a day and I wouldn't be surprised if there were > numerous bugs or points of attack [I've fixed a dozen since last > night]. [Standard rant follows... :)] I'm trying to figure out why this is a good idea even in principle. I've seen <100k SSL implementations and that included the ASN.1 processing for certs. I would imagine that one could do a compliant SSL implementation that used fixed RSA keys in roughly the same code size as your stuff. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
