Re: Maybe It's Snake Oil All the Way Down

John Kelsey wrote: > So, what can I do about it, as an individual? Make the cellphone companies > build good crypto into their systems? Any ideas how to do that? Nope. Cellphone companies are big slow moving targets. They get their franchise from the government. If the NSA wants weak crypto,

Re: Maybe It's Snake Oil All the Way Down

Derik asks the pertinant question: > The question is: how do we convince M$ and Netscape to include something > else in their software? If it's not supported in IE, then it wont be > available to the vast majority of users out there. My view, again, IMHO: ignore Microsoft. Concentrate on the o

"PGP Encryption Proves Powerful"

The following appears to be a bone fide case of a threat model in action against the PGP program. Leaving aside commentary on the pros and cons within this example, there is a desparate lack of real experience in how crypto systems are attacked. IMHO, this leads to some rather poorly chosen engine

Re: "PGP Encryption Proves Powerful"

John Kelsey wrote: > > At 10:29 AM 5/30/03 -0400, Anton Stiglic wrote: > > >So what happened to passphrase guessing? That's got to be > >one of the weakest links. Unless their private key wasn't > >stored on the device? > > One thought: How hard would it be to write a Palm app to use the > in

Re: Maybe It's Snake Oil All the Way Down

A lot of the tools and blocks are too hard to understand. "Inaccessible" might be the proper term. This might apply to, for example, SSL, and more so to IPSec. These have a lower survival rate, simply because as developers look at them, their eyes glaze over and they move on. I heard one guy s

Re: Maybe It's Snake Oil All the Way Down

Eric Murray wrote: > > On Mon, Jun 02, 2003 at 10:09:06AM -0400, Ian Grigg wrote: > > A lot of the tools and blocks are too hard to > > understand. "Inaccessible" might be the proper > > term. This might apply to, for example, SSL, > > and more so to IPSe

Re: Maybe It's Snake Oil All the Way Down

Eric Rescorla wrote: > > Ian Grigg <[EMAIL PROTECTED]> writes: > > Eric Murray wrote: > > It may be that the SSL underlying code is > > perfect. But that the application is weak > > because the implementor didn't understand > > how to drive it; in

Ntru suffers 'chosen ciphertext attack'

Ntru gets into trouble when their proprietary crypto hits a security bug... "The technology was perceived to be better, but it's not good enough to overcome the objection that no one gets fired for buying RSA [Security Inc.products]," said one person close to Ntru. :-) Apropos to the

Re: Maybe It's Snake Oil All the Way Down

Lucky Green wrote: > > Ian Grigg wrote: > > Also, a lot of cryptosystems are put together > > by committees. SSH was originally put together > > by one guy. He did the lot. Allegedly, a fairly > > grotty protocol with a number of weakneses, but > > it was

Re: Maybe It's Snake Oil All the Way Down

Bill Stewart wrote: > > At 11:38 AM 06/03/2003 -0400, Ian Grigg wrote: > >I (arbitratrily) define the marketplace for SSL as browsing. > ... > >There, we can show statistics that indicate that SSL > >has penetrated to something slightly less than 1% of servers. >

Re: Maybe It's Snake Oil All the Way Down

Tim Dierks wrote: > > At 09:11 AM 6/3/2003, Peter Gutmann wrote: > >"Lucky Green" <[EMAIL PROTECTED]> writes: > > >Given that SSL use is orders of magnitude higher than that of SSH, with no > > >change in sight, primarily due to SSL's ease-of-use, I am a bit puzzled by > > >your assertion that ssh

Re: CDR: Re: Maybe It's Snake Oil All the Way Down

Sampo Syreeni wrote: > >But anything that goes over the air, whether cellphone or cordless phone, > >ought to be properly encrypted, and it isn't now. > > Why? As I see it, this is fundamentally an economic question, not a > technical one. It's about the risk of somebody listening in, taking noti

Re: Session Fixation Vulnerability in Web Based Apps

Ben Laurie wrote: > > James A. Donald wrote: > > I do not see how this flaw can be avoided unless one > > consciously takes special measures that the development > > environment is not designed or intended to support. > > The obvious answer is you always switch to a new session after login. > No

Re: An attack on paypal

Matthew Byng-Maddick wrote: > > On Fri, Jun 13, 2003 at 04:32:12PM -0700, Bill Stewart wrote: > > An e-gold-specific or paypal-specific client can tell, > > because it can remember that it's trying to see the real thing, > > but the browser can't tell, except by bugging you about > > "Hi, this is

Mozilla tool to self-verify HTTPS site

http://sslbar.metropipe.net/ Fantastic news: coders are starting to work on the failed security model of secure browsing and improve it where it matters, in the browser. This plugin for Mozilla shows the SSL certificate's fingerprint on the web browser's toolbar. It's a small step for the user,

Re: Mozilla tool to self-verify HTTPS site

[EMAIL PROTECTED] wrote: > How many users can remember MD5 checksums??? If they were rendered into > something pronounceable via S/Key like dictionaries it might be more > useful... You forgot this bit: > It's a small step for the user, but a giant leap > for userland security. It means that so

Re: Mozilla tool to self-verify HTTPS site

[EMAIL PROTECTED] wrote: > How many users can remember MD5 checksums??? If they were rendered into > something pronounceable via S/Key like dictionaries it might be more > useful... Apologies, last night's answer was too brief to be useful! Here's the more detailed and coffee charged explanation

Re: New toy: SSLbar

"Steven M. Bellovin" wrote: > Please don't take this personally... None taken here, and I doubt that the author of the tool (who has just joined this list it seems) would take any! > >From a security point of view, why should anyone download any plug-in > from an unknown party? In this very spe

Re: Mozilla tool to self-verify HTTPS site

Marc Branchaud wrote: > > Ian Grigg wrote: > > > > Tying the certificate into the core crypto protocol seems to be a > > poor design choice; outsourcing any certification to a higher layer > > seems to work much better out in the field. > > I'll re

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 tho

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 require

Re: Fwd: [IP] A Simpler, More Personal Key to Protect OnlineMessages

Tim Dierks wrote: ... > the fact that the private key, is, in essence, escrowed by the trusted > third party, causes me to believe that this system doesn't fill an > important unmet need. I'm not sure that's the case! There are some markets out there where there are some contradictory rules. By

replay & integrity

Eric Rescorla wrote: > You keep harping on certs, but that's fundamentally not relevant to > the point I was trying to make, OK! > which is whether or not one provides > proper message integrity and anti-replay. As far as I'm concerned, > there are almost no situations in which not providing tho

Re: SSL

[EMAIL PROTECTED] wrote: > Instead, I have a > different question: Where can I learn about SSL? Most people seem to think the RFC is unreadable, so ... > As in, could someone reccommend a good book, or online tutorial, or > something, somewhere, that explains it all from pretty much first > prin

Re: Announcing httpsy://, a YURL scheme

Ed Gerck wrote: > > >From your URLs: > > "The browser verifies that the fingerprint in the URL matches the public key > provided by the visited site. Certificates and Certificate Authorities are > unnecessary. " I agree that the last part is a little aggressive. "Unnecessary" is so ... final.

Re: Announcing httpsy://, a YURL scheme

Ed Gerck wrote: > > Ian Grigg wrote: > > > Ed Gerck wrote: > > > Not that I believe CAs are essential (I don't, for reasons already presented in > > > '97), > > > but unless the issues of spoofing, MITM and revocation are adequately hand

[Fwd: BugTraq - how to coverup the security]

Over on BugTraq, there is a new security flaw being demonstrated that allows a page to cover up various of the security components for an IE browser. I can't see them on my browser, but what I saw on an IE equipped browser was good enough to fool some people. It's worth checking out! It really d

Re: [Fwd: BugTraq - how to coverup the security]

Sean, I apologise for the snippety email last night, I obviously missed the point completely! Sean Smith wrote: > > > > Are other platforms more secure or do they just receive > > > less scrutiny? Or is it that Microsoft does not react quickly to > > > found bugs? . > > My point was just t

Re: Announcing httpsy://, a YURL scheme

[EMAIL PROTECTED] wrote: > A YURL aware search engine may find multiple independent references to a > YURL, thus giving you parallel reporting channels, and increasing trust. > Of course, this method differs from the YURL method for trust. The > parallel channel method assigns a trust value to a s

3 more good ideas: cryptoURLs, SFS, eternal resource locator/WAX

Below follows a paragraph on each idea to distribute key hashes within existing web practice, with examples. Trevor Perrin wrote: > A similar idea was discussed on the W3C's URI list[1]. Simon Josefsson had > the clever idea of a URI scheme that binds an underlying URI to some > "crypto data" su

Re: Announcing httpsy://, a YURL scheme

"Perry E. Metzger" wrote: > 1) The "YURL" makes key management and replacement effectively >impossible. Well, I would have said it suggests a different method. Instead of regimented, hierarchical and fixed key management - an idea of poor track record - the key management issue here is pushe

Re: Announcing httpsy://, a YURL scheme

"Perry E. Metzger" wrote: > I'm talking about replacing keys. We were indeed talking about different things. I'll address that here then. > Almost every protocol out there lets > you replace your keys at periodic intervals. Proper key hygiene > dictates that you change your keys often enough th

[Fwd: [fc-announce] FC '04: Call for Papers]

Original Message From: "Juels, Ari" <[EMAIL PROTECTED]> Subject: [fc-announce] FC '04: Call for Papers To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Call for Papers and Presentations Financial Cryptography '04 9-12 February 2004 Key West, Florida, USA Conference Web site:

invoicing with PKI

Does anyone know any instances of invoicing and contracting systems that use PKI and digital orders? That is, purchasing departments and selling departments communicating with digitally signed contracts, purchase orders, delivery confirmations and so forth. And, the normal skeptical followup ques

[Fwd: [fc-announce] FC '04: Extended submission deadline]

Original Message From: "Juels, Ari" <[EMAIL PROTECTED]> Subject: [fc-announce] FC '04: Extended submission deadline To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> *** Extended Deadline *** Call for Papers and Presentations Financial Cryptography '04 9-12 February 2004 Key West

Re: invoicing with PKI

(Things seem quiet on the crypto front, here's a late reply.) Hadmut Danisch wrote: > > Hi, > > On Thu, Jul 17, 2003 at 04:27:52PM -0400, Ian Grigg wrote: > > Does anyone know any instances of invoicing and > > contracting systems that use PKI and digital orders

Is cryptography where security took the wrong branch?

Hadmut Danisch wrote: > The reason I was asking is: I had a dispute with someone who > claimed that cryptography is by far the most important discipline > of information and communication security, and that its transition > from an art to a science was triggered by Shannon's paper in 1949 > and th

Re: invoicing with PKI

Peter Gutmann wrote: > > Hadmut Danisch <[EMAIL PROTECTED]> writes: > > >There was an interesting speech held on the Usenix conference by Eric > >Rescorla (http://www.rtfm.com/TooSecure-usenix.pdf, unfortunately I did not > >have the time to visit the conference) about cryptographic (real world)

Re: Is cryptography where security took the wrong branch?

Eric Rescorla wrote: > > Ian Grigg <[EMAIL PROTECTED]> writes: > > That's a scary talk! I see a lot of familiar > > stuff, but it seems that whilst Eric courts the > > dark side of real security, he holds back from > > really letting go and getting stuck

SSL's threat model

Does anyone have any pointers to the SSL threat model? I have Eric Rescorla's book and slides talking about the Internet threat model. The TLS RFC (http://www.faqs.org/rfcs/rfc2246.html) says nothing about threat models that I found. iang

Re: Is cryptography where security took the wrong branch?

Eric Rescorla wrote: > > b. we seem to be agreeing on 1% penetration of > > the market, at least by server measurement (see > > my other post where I upped that to 1.24% in the > > most recent figures). > This really depends on your definition of market. > SSL was designed to protect credit card tr

Re: Is cryptography where security took the wrong branch?

Eric Rescorla wrote: ... > > The other thing to be aware of is that ecommerce itself > > is being stinted badly by the server and browser limits. > > There's little doubt that because servers and browsers > > made poorly contrived decisions on certificates, they > > increased the overall risks to t

Re: Is cryptography where security took the wrong branch?

Eric Rescorla wrote: > > Ian Grigg <[EMAIL PROTECTED]> writes: > > > Eric Rescorla wrote: > > ... > > > > The other thing to be aware of is that ecommerce itself > > > > is being stinted badly by the server and browser limits. > > &

Re: Is cryptography where security took the wrong branch?

Ed, I've left your entire email here, because it needs to be re-read several times. Understanding it is key to developing protocols for security. Ed Gerck wrote: > > Arguments such as "we don't want to reduce the fraud level because > it would cost more to reduce the fraud than the fraud costs"

Re: Is cryptography where security took the wrong branch?

Eric Rescorla wrote: > Elasticity is about how much consumption changes when price > changes, not about what people who were already going to buy > choose to buy. Sorry, Eric, I'm not quite with you on this... You said: > > Maybe, maybe not. You've never heard of price inelasticity? You haven'

Re: Code breakers crack GSM cellphone encryption

"Trei, Peter" wrote: > Why the heck would a government agency have to break the GSM encryption > at all? Once upon a time, it used to be the favourite sport of spy agencies to listen in on the activities of other countries. In that case, access to the radio waves was much more juicy than access

Re: Digital cash and campaign finance reform

Steve Schear wrote: > By combining a mandated digital cash system for contributions, a cap on the > size of each individual contribution (perhaps as small as $100), randomized > delays (perhaps up to a few weeks) in the "posting" of each transaction to > the account of the counter party, it could

x9.59

Anne & Lynn Wheeler wrote: > > The result is X9.59 which addresses all the major > exploits at both POS as well as internet (and not just credit, but debit, > stored-value, ACH, etc ... as well). > http://www.garlic.com/~lynn/index.html#x959 Lynn, Whatever happened to x9.59? Also, is there a

Re: Code breakers crack GSM cellphone encryption

David Wagner wrote: > > Vin McLellan wrote: > >A5/2 was the equivalent of 40-bit DES, presumed to be relatively weak and > >developed as an export standard. > > Yeah. Except it would be more accurate to place A5/2's strength as > roughly equivalent to 17-bit DES. A5/1's strength is roughly equ

Re: quantum hype

David Wagner wrote: > One could reasonably ask how often it is in practice that we have a > physical channel whose authenticity we trust, but where eavesdropping > is a threat. I don't know. The only answer that I have come across - to which I ascribe no view on accuracy - is "undersea fibre" [1

Re: PGP makes email encryption easier

"R. A. Hettinga" wrote: > PGP Corp has taken a slightly different tack, adapting its software so that it can > be loaded onto x86 servers to create an email encryption appliance. These proxy > servers live between an email server and client machine or in an enterprise's DMZ; > they are responsi

Re: PGP makes email encryption easier

Eric Murray wrote: > > For the record, AFAIK, this approach was invented and > > deployed by Dr. Ian Brown as his undergraduate thesis, > > back in 1996 or so. > > Not to take anything away from Dr Brown, but I wrote something very > similar to what PGP's selling for internal use at SUN in 1995 (

Simple inner transposition steganography

I'm not sure if this is novel, but it's new to me, and a lot of fun to brighten up our otherwise dull day. Some guys over on dgcchat have stumbled on a simple steganography method. What follows is their own words, but in an edited single sequence: === Ragnar:

Re: Simple inner transposition steganography

Bill Stewart wrote: > > Ian Grigg wrote: > > Ken Griffith adds: > > Taht wulod be an execlenlt way to sned emial msesgaes in palin txet taht > > cnnaot be dteetced by ehceoln. One culod tlak aoubt bmbos, trerroitss and > > suftf lkie taht wiohtut trgigreing the fag

Re: Simple inner transposition steganography

edo wrote: > > Come on, this is a terrible idea for steganography. Unless this catches > on as some sort of fad, which (a) it won't and (b) even if it did it > would be short-lived, then sending a message with its letters scrambled > in this way would be the last thing you'd want to do for stegan

Re: quantum hype

"R. Hirschfeld" wrote on QKD: > The eavesdropper Eve doesn't know with which basis to measure the > polarity of the each intercepted photon. When she guesses right, she > gets the correct information and can send it on undetectably. When > she guesses wrong, she gets a zero or one with equal pro

Can Eve repeat?

"R. Hirschfeld" wrote: > > > Date: Fri, 19 Sep 2003 11:57:22 -0400 > > From: Ian Grigg <[EMAIL PROTECTED]> > > > If I understand this correctly, this is both > > an eavesdropping scenario and an MITM scenario. > > > > In the ab

The Code Book - in CD form

Has anyone reviewed Simon Singh's CD version of "The Code Book" ? = http://www.simonsingh.net/The_CDROM.html After 12 months of intense development, the interactive CD-ROM version of The Code Book is now available. I might be biased, but I think that i

Re: Who is this Mallory guy anyway?

> someone wrote: > > Hiya. > > Dumb question. Why is the bad guy called Mallory in > this thread? I always thought that traditionally the > two correspondents were called Alice and Bob and that > the bad guy was called Eve. (As in, short for eavesdropper?). > Intercepting the bits and sending the

Re: why are CAs charging so much for certs anyway? (Re: End of the line for Ireland's dotcom star)

Adam Back wrote: > You'd have thought there would be plenty of scope for certs to be sold > for a couple of $ / year. Excuse me? Why are they being sold "per year" in the first place? It's not as if there are any root servers to run! Outrageous! :-) iang

Re: Reliance on Microsoft called risk to U.S. security

"R. A. Hettinga" wrote: > > > > Reliance on Microsoft called risk to U.S. security > But the security experts said the issue of computer security > had more to do with the ubiquity of Micros

Re: Tinc's response to "Linux's answer to MS-PPTP"

M Taylor wrote: > Oh, and they fixed their flaws. SSHv1 is not recommended for use at all, > and most systems use SSHv2 now which is based upon a draft IETF standard. > SSL went through SSLv1, SSLv2, SSLv3, TLSv1.0, and TLSv1.1 is a draft IETF > standard. It is curious, is it not, that there has

Re: Monoculture

Matt Blaze wrote: > > > I imagine the Plumbers & Electricians Union must have used similar > > arguments to enclose the business to themselves, and keep out unlicensed > > newcomers. "No longer acceptable" indeed. Too much competition boys? > > > > Rich, > > Oh come on. Are you willfully misinte

Re: Monoculture

Don Davis wrote: > > EKR writes: > > I'm trying to figure out why you want to invent a new authentication > > protocol rather than just going back to the literature ... > note that customers aren't usually dissatisfied with > the crypto protocols per se; they just want the > protocol's implement

Re: Monoculture

"Perry E. Metzger" wrote: ... >Dumb cryptography kills people. What's your threat model? Or, that's your threat model? Applying the above threat model as written up in "The Codebreakers" to, for example, SSL and its original credit card nreeds would seem to be a mismatch. On the face of

Re: anonymous DH & MITM

M Taylor wrote: > > Stupid question I'm sure, but does TLS's anonymous DH protect against > man-in-the-middle attacks? If so, how? I cannot figure out how it would, Ah, there's the rub. ADH does not protect against MITM, as far as I am aware. > and it would seem TLS would be wide open to abus

Re: VeriSign tapped to secure Internet voting

"Roy M. Silvernail" wrote: > > On Wednesday 01 October 2003 17:33, R. A. Hettinga forwarded: > > > VeriSign tapped to secure Internet voting > > > "The solution we are building will enable absentee voters to exercise > > their right to vote," said George Schu, a vice president at VeriSign. "The

Re: anonymous DH & MITM

"Steven M. Bellovin" wrote: > > In message <[EMAIL PROTECTED]>, Ian Grigg writes: > >M Taylor wrote: > > > > >MITM is a real and valid threat, and should be > >considered. By this motive, ADH is not a recommended > >mode in TLS, and

crypto licence

Guus Sliepen wrote: > > Some advice on licensing wouldn't go amiss either. (GPL? ... LGPL? ... > > something else?) > > I'd say LGPL or BSD, without any funny clauses. With crypto code, we have taken the view that it should BSD 2 clause. The reason for this is that crypto code has enough other

using SMS challenge/response to secure web sites

Merchants who *really* rely on their web site being secure are those that take instructions for the delivery of value over them. It's a given that they have to work very hard to secure their websites, and it is instructive to watch their efforts. The cutting edge in making web sites secure is occ

Re: Simple SSL/TLS - Some Questions

Jill Ramonsky wrote: > > Having been greatly encouraged by people on this list to go ahead with a > new SSL implementation, it looks like I am going to go for it, but I'd > kinda like to not make any enemies in the process so I'll try to keep > this list up to date with progress and decisions and

Re: anonymous DH & MITM

"R. A. Hettinga" wrote: > > At 2:16 PM -0700 10/2/03, bear wrote: > >That's not anonymity, that's pseudonymity. > > It seems to me that perfect pseudonymity *is* anonymity. Conventionally, I think, Anonymity is when one publishes a pamphlet of political criticism, and there is no name on the pam

threat modelling strategies

"Arnold G. Reinhold" wrote: > > At 11:50 PM -0400 10/1/03, Ian Grigg wrote: > >... > >A threat must occur sufficiently in real use, and incur > >sufficient costs in excess of protecting against it, in > >order to be included in the threat model on its merit

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 difficul

Re: anonymous DH & MITM

Taral wrote: > > On Mon, Oct 06, 2003 at 11:43:21AM -0400, Anton Stiglic wrote: > > You started by talking about anonymous communication, but ended up > > suggesting a scheme for pseudonymous communication. > > > > Anonymous != pseudonymous. > > > > Let us be clear on that! > > It is an important

Re: Simple SSL/TLS - Some Questions

Jill Ramonsky wrote: > First, the primary design goal is "simple to use". This is the highest goal of all. If it is not simple to use, it misses out on a lot of opportunities. And missing out results in less crypto being deployed. If you have to choose between simple-but-incomplete, versus co

Re: anonymity +- credentials

Anton Stiglic wrote: > > >We need a practical system for anonymous/pseudonymous > > >credentials. Can somebody tell us, what's the state of > > >the art? What's currently deployed? What's on the > > >drawing boards? > > > > The state of the art, AFAIK, is Chaum's credential system. > > The sta

Re: Simple SSL/TLS - Some Questions

Jill Ramonsky wrote: > > The only question I wasn't quite sure of > > was whether, if I take your code, and modify it, > > can I distribute a binary only version, and keep > > the source changes proprietary? > > You can't distribute a binary only version of ANY crypto product, > surely? No cr

Re: Simple SSL/TLS - Some Questions

Anne & Lynn Wheeler wrote: > > At 12:09 PM 10/7/2003 -0700, Eric Rescorla wrote: > >This doesn't provide equivalent services to TLS--no anti-replay > >service for the server. > > KISS ... for the primary business requirement the application already > has anti-replay TLS ant-replay is th

credit card threat model

Anne & Lynn Wheeler wrote: > what i said was that it was specifying a simplified SSL/TLS based on the > business requirements for the primary use of SSL/TLS as opposed to a > simplified SSL/TLS based on the existing technical specifications and > existing implementations. I totally agree th

Re: anonymity +- credentials

Anton Stiglic wrote: > > - Original Message - > From: "Ian Grigg" <[EMAIL PROTECTED]> > > > [...] > > In terms of actual "practical" systems, ones > > that implement to Brands' level don't exist, > > as far as I know

Re: [dgc.chat] EU directive could spark patent war

Steve Schear wrote: > > [I wonder what if any effect this might have on crypto patents, e.g., > Chaumian blinding?] My guess is, nix, nada. Patents are a red herring in the blinding skirmishes, they became a convenient excuse and a point to place the flag when rallying the troops. The battle w

Easy VPNs?

I'm curious - my understanding of a VPN was that it set up a network that all applications could transparently communicate over. Port forwarding appears not to be that, in practice each application has to be reconfigured to talk to the appropriate port, or, each port has to be forwarded. Am I mis

Re: NCipher Takes Hardware Security To Network Level

Anton Stiglic wrote: > > - Original Message - > From: "Peter Gutmann" <[EMAIL PROTECTED]> > > [...] > > > > The problem is > > that what we really need to be able to evaluate is how committed a vendor > is > > to creating a truly secure product. > > [...] > > I agree 100% with what you sa

Re: Easy VPNs?

Dave Howe wrote: > so as I say - think of vpn as two components - intercept (the virtual > network functionality) and transport (a secure, authenticated, > encapsulated communications standard) and how vpn over *anything* becomes > more clear. Thanks. That's the key! Then, the answer might rea

WYTM?

As many have decried in recent threads, it all comes down the WYTM - What's Your Threat Model. It's hard to come up with anything more important in crypto. It's the starting point for ... every- thing. This seems increasingly evident because we haven't successfully reverse-engineered the threat

Re: WYTM?

Minor errata: Eric Rescorla wrote: > I totally agree that the systems are > insecure (obligatory pitch for my "Internet is Too > Secure Already") http://www.rtfm.com/TooSecure.pdf, I found this link had moved to here; http://www.rtfm.com/TooSecure-usenix.pdf > which makes some of the same

Re: WYTM?

Eric, thanks for your reply! My point is strictly limited to something approximating "there was no threat model for SSL / secure browsing." And, as you say, you don't really disagree with that 100% :-) With that in mind, I think we agree on this: > > [9] I'd love to hear the inside scoop, but

Re: WYTM?

Eric Rescorla wrote: > > Ian Grigg <[EMAIL PROTECTED]> writes: > > > It's really a mistake to think of SSL as being designed > > > with an explicit threat model. That just wasn't how the > > > designers at Netscape thought, as far as I can tell.

Re: WYTM?

Eric Rescorla wrote: > > Ian Grigg <[EMAIL PROTECTED]> writes: > > I'm sorry, but, yes, I do find great difficulty > > in not dismissing it. Indeed being other than > > dismissive about it! > > > > Cryptography is a special product, it may > >

Re: WYTM?

Tim Dierks wrote: > > At 12:28 AM 10/13/2003, Ian Grigg wrote: > >Problem is, it's also wrong. The end systems > >are not secure, and the comms in the middle is > >actually remarkably safe. > > I think this is an interesting, insightful analysis, but I a

Re: WYTM?

Jon Snader wrote: > > On Mon, Oct 13, 2003 at 06:49:30PM -0400, Ian Grigg wrote: > > Yet others say "to be sure we are talking > > to the merchant." Sorry, that's not a good > > answer either because in my email box today > > there are about 10 dif

Re: SSL, client certs, and MITM (was WYTM?)

Tom Otvos wrote: > As far as I can glean, the general consensus in WYTM is that MITM attacks are very > low (read: > inconsequential) probability. Is this *really* true? The frequency of MITM attacks is very low, in the sense that there are few or no reported occurrences. This makes it a chal

Re: SSL, client certs, and MITM (was WYTM?)

Tom Weinstein wrote: > > Ian Grigg wrote: > > > Nobody doubts that it can occur, and that it *can* occur in practice. > > It is whether it *does* occur that is where the problem lies. > > This sort of statement bothers me. > > In threat analysis, yo

Re: SSL, client certs, and MITM (was WYTM?)

"Perry E. Metzger" wrote: > > Ian Grigg <[EMAIL PROTECTED]> writes: > > In threat analysis, you base your assessment on > > economics of what is reasonable to protect. It > > is perfectly valid to decline to protect against > > a possible threat, if

Re: SSL, client certs, and MITM (was WYTM?)

Tom Weinstein wrote: > The economic view might be a reasonable view for an end-user to take, > but it's not a good one for a protocol designer. The protocol designer > doesn't have an economic model for how end-users will end up using the > protocol, and it's dangerous to assume one. This is espec

Re: A-B-a-b encryption

martin f krafft wrote: > > it came up lately in a discussion, and I couldn't put a name to it: > a means to use symmetric crypto without exchanging keys: > > - Alice encrypts M with key A and sends it to Bob > - Bob encrypts A(M) with key B and sends it to Alice > - Alice decrypts B(A(M)) w

Cryptophone locks out snoopers

(link is very slow:) http://theregister.co.uk/content/68/34096.html Cryptophone locks out snoopers By electricnews.net Posted: 20/11/2003 at 10:16 GMT A German firm has launched a GSM mobile phone that promises strong end-to-end encryption on calls, preventing the possibility of anybody listen

Re: Open Source Embedded SSL - (License and Memory)

J Harper wrote: > > > 1) Not GPL or LPGL, please. I'm a fan of the GPL for most things, but > > > for embedded software, especially in the security domain, it's a > > killer. I'm supposed to allow users to modify the software that runs > > on their secure token? And on a small platform where t

Re: Larry Lessig on ending anonymity through "identity escrow"

It seems as if Larry Lessig has figured out the fatal flaw in anonymous or untraceable systems - that they are not economically sustainable. In the face of that argument, he does not propose that they be banned, as Declan suspects: > [Why do I get the feeling that Larry Lessig doesn't like "absol

  1   2   3   >