Victor Duchovni writes:
| ...
| The personal ATM appliance should be difficult to tamper with and should
| accept only a single set of accounts (so that stolen pin numbers are not
| portable)...
My personal guess is that the general purpose
computer is ultimately a goner -- it will later,
if
Pat Farrell wrote:
"the only secure computer is turned off, unplugged,
inside a SCIF and surrounded by US Marines."
... provided you can trust the marines.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cry
On 6/27/05, Victor Duchovni <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 27, 2005 at 09:58:31AM -0600, Chris Kuethe wrote:
>
> > And now we have a market for cracked "trusted" banking clients, both
> > for phishers and lazy people... it's game copy protection wars all
> > over again. :)
> >
>
> Well
On Mon, Jun 27, 2005 at 09:58:31AM -0600, Chris Kuethe wrote:
> And now we have a market for cracked "trusted" banking clients, both
> for phishers and lazy people... it's game copy protection wars all
> over again. :)
>
Well cracking the bank application is not really in the user's interests
in
On Mon, 2005-06-27 at 10:19 -0400, John Denker wrote:
> Even more compelling is:
> -- obtain laptop hardware from a trusted source
> -- obtain software from a trusted source
> -- throw the entire laptop into a GSA-approved safe when
>not being used.
This is just a minor variation of an a
On 6/26/05, Dan Kaminsky <[EMAIL PROTECTED]> wrote:
> It is not necessary though that there exists an acceptable solution that
> keeps PC's with persistent stores secure. A bootable CD from a bank is
> an unexpectedly compelling option, as are the sort of services we're
> going to see coming out o
On 06/27/05 00:28, Dan Kaminsky wrote:
... there exists an acceptable solution that
keeps PC's with persistent stores secure. A bootable CD from a bank is
an unexpectedly compelling option
Even more compelling is:
-- obtain laptop hardware from a trusted source
-- obtain software from a tru
>If you are insisting that there is always
>a way and that, therefore, the situation is
>permanently hopeless such that the smart
>ones are getting the hell out of the
>Internet, I can go with that, but then
>we (you and I) would both be guilty of
>letting the best be the enemy of the good.
>
>
Dan Kaminsky writes:
| Dan--
|
| I had something much more complicated, but it comes down to.
|
| You trust Internet Explorer.
| Spyware considers Internet Explorer crunchy, and good with ketchup.
| Any questions?
|
| A little less snarkily, Spyware can trivially use w
Dan--
I had something much more complicated, but it comes down to.
You trust Internet Explorer.
Spyware considers Internet Explorer crunchy, and good with ketchup.
Any questions?
A little less snarkily, Spyware can trivially use what MS refers to
as a Browser Helper Object (B
What do you tell people to do?
Defense in depth, as always. As an officer at
Verdasys, data-offload is something we block
by simply installing rules like "Only these
two trusted applications can initiate outbound
HTTP" where the word "trusted" means checksummed
and the choice of HTTP represent
Allan Liska wrote:
3. Use an on-screen keyboard.
For extra points, try Dasher.
http://www.inference.phy.cam.ac.uk/dasher/
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man
Adam Shostack wrote:
On Wed, Jun 22, 2005 at 01:54:34PM +0100, Ian Grigg wrote:
| A highly aspirated but otherwise normal watcher of black helicopters asked:
|
| > Any idea if this is true?
| > (WockerWocker, Wed Jun 22 12:07:31 2005)
| > http://c0x2.de/lol/lol.html
|
| Beats me. But what i
Ian Grigg wrote:
A highly aspirated but otherwise normal watcher of black helicopters asked:
Any idea if this is true?
(WockerWocker, Wed Jun 22 12:07:31 2005)
http://c0x2.de/lol/lol.html
Beats me. But what it if it was true. What's your advice to
clients?
First up, it certainly is not
On Wed, 22 Jun 2005, Ian Grigg wrote:
A highly aspirated but otherwise normal watcher of black helicopters asked:
Any idea if this is true?
(WockerWocker, Wed Jun 22 12:07:31 2005)
http://c0x2.de/lol/lol.html
googling 'dell keylogger' certainly turns up a lot of sites who insist
that this
It is most likely a hoax:
http://www.boingboing.net/2005/06/16/conspiracy_theory_of.html
As to your second question. There are several options available to you
depending on your level of paranoia:
1. Run a personal firewall (assuming you can find one that doesn't have
a trojan that talks ba
On Wed, Jun 22, 2005 at 01:54:34PM +0100, Ian Grigg wrote:
| A highly aspirated but otherwise normal watcher of black helicopters asked:
|
| > Any idea if this is true?
| > (WockerWocker, Wed Jun 22 12:07:31 2005)
| > http://c0x2.de/lol/lol.html
|
| Beats me. But what it if it was true. What's
A highly aspirated but otherwise normal watcher of black helicopters asked:
> Any idea if this is true?
> (WockerWocker, Wed Jun 22 12:07:31 2005)
> http://c0x2.de/lol/lol.html
Beats me. But what it if it was true. What's your advice to
clients?
iang
--
Advances in Financial Cryptography, Is
> I'm not sure how you come to that conclusion. Simply
> use TLS with self-signed certs. Save the cost of the
> cert, and save the cost of the re-evaluation.
>
> If we could do that on a widespread basis, then it
> would be worth going to the next step, which is caching
> the self-signed certs,
At 07:11 PM 10/22/03 -0400, Perry E. Metzger wrote:
>
>Indeed. Imagine if we waited until airplanes exploded regularly to
>design them so they would not explode, or if we had designed our first
>suspension bridges by putting up some randomly selected amount of
>cabling and seeing if the bridge coll
Internet groups starts anit-hacker initiative
http://www.computerweekly.com/articles/article.asp?liArticleID=125823&liArti
cleTypeID=1&liCategoryID=2&liChannelID=22&liFlavourID=1&sSearch=&nPage=1
one of the threats discussed in the above is the domain name ip-address
take-over mentioned previous
- Original Message -
From: "Tom Otvos" <[EMAIL PROTECTED]>
> As far as I can glean, the general consensus in WYTM is that MITM attacks
are very low (read:
> inconsequential) probability.
I'm not certain this was the consensus.
We should look at the scenario
[EMAIL PROTECTED] (David Wagner) writes:
>When I establish a credit card with Visa, I generate a new client certificate
>for this purpose and register it with www.visa.com. When I want to buy a
>fancy hat from www.amazon.com, Amazon re-directs me to
>https://ssl.visa.com/buy.cgi?payto=amazon&amou
"Perry E. Metzger" <[EMAIL PROTECTED]> writes:
>TLS is just a pretty straightforward well analyzed protocol for protecting a
>channel -- full stop. It can be used in a wide variety of ways, for a wide
>variety of apps. It happens to allow you to use X.509 certs, but if you
>really hate X.509, defi
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
Thor Lancelot Simon wrote:
>Can you please posit an *exact* situation in which a man-in-the-middle
>could steal the client's credit card number even in the presence of a
>valid server certificate?
Sure. If I can assume you're talking about SSL/https as it is
typically used in ecommerce today, th
Ian Grigg <[EMAIL PROTECTED]> writes:
> "Perry E. Metzger" wrote:
> > The cost of MITM protection is, in practice, zero.
>
> Not true! The cost is from 10 million dollars to
> 100 million dollars per annum. Those certs cost
> money, Perry!
They cost nothing at all. I use certs every day that I
"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 the cost thereof is too high,
> > as compared a
Ian Grigg wrote:
Tom Weinstein wrote:
In threat analysis, you have to base your assessment on capabilities,
not intentions. If an attack is possible, then you must guard against
it. It doesn't matter if you think potential attackers don't intend to
attack you that way, because you really don't
At 05:42 PM 10/22/2003 -0400, Tom Otvos wrote:
Absolutely true. If the "only" effect of a MITM is loss of privacy, then
that is certainly a
lower-priority item to fix than some quick cash scheme. So the "threat
model" needs to clearly
define who the bad guys are, and what their motivations are
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 the cost thereof is too high,
> as compared against the benefits.
The cost of MITM p
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, you have to base your assessment on capabilities
[EMAIL PROTECTED] (David Wagner) writes:
> 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?
>
> I'm not aware of any such consensus.
I
On Wed, Oct 22, 2003 at 05:08:32PM -0400, Tom Otvos wrote:
> >
> > So what purpose would client certificates address? Almost all of the use
> > of SSL domain name certs is to hide a credit card number when a consumer
> > is buying something. There is no requirement for the merchant to
> > identify
Ian Grigg <[EMAIL PROTECTED]> writes:
> 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.
>
> The question is one of costs and benefits - how much
> should we spend to defend against this attack? How
> much do
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?
I'm not aware of any such consensus.
I suspect you'd get plenty of debate on this point.
But in any case, wide
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, you have to base your assessment on capabilities,
not intentions. If an attack is possible,
>
> 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.
>
Or, whether it gets reported if it does occur.
> The question is one of costs and benefits - how much
> should we spend to defend against this attack? Ho
At 05:08 PM 10/22/2003 -0400, Tom Otvos wrote:
The CC number is clearly not hidden if there is a MITM. I think the "I
got my money so who cares
where it came from" argument is not entirely a fair
representation. Someone ends up paying for
abuses, even if it is us in CC fees, otherwise why both
On 10/22/2003 04:33 PM, Ian Grigg wrote:
>
> The frequency of MITM attacks is very low, in the sense that there
> are few or no reported occurrences.
We have a disagreement about the facts on this point.
See below for details.
> This makes it a challenge to
> respond to in any measured way.
We have
>
> So what purpose would client certificates address? Almost all of the use
> of SSL domain name certs is to hide a credit card number when a consumer
> is buying something. There is no requirement for the merchant to
> identify and/or authenticate the client the payment infrastructure
> auth
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
m
On Wed, 2003-10-22 at 13:46, Tom Otvos wrote:
> I read the "WYTM" thread with great interest because it dovetailed nicely with some
> research I am
> currently involved in. But I would like to branch this topic onto something
> specific, to see what
> everyone here thi
I read the "WYTM" thread with great interest because it dovetailed nicely with some
research I am
currently involved in. But I would like to branch this topic onto something specific,
to see what
everyone here thinks.
As far as I can glean, the general consensus in WYTM is that MI
On Tue, 21 Oct 2003 15:02:14 +1300, Peter Gutmann said:
> Are there any known servers online that offer X.509 (or PGP) mechanisms in
> their handshake? Both ssh.com and VanDyke are commercial offerings so it's
> not possible to look at the source code to see what they do, and I'm not sure
Joel N
Thor Lancelot Simon <[EMAIL PROTECTED]> writes:
>I believe the VanDyke implementation also supports X.509, and interoperates
>with the ssh.com code. It was also my perception that, at the time, the
>VanDyke guy was basically shouted down when trying to discuss the utility of
>X.509 for this purpo
On Sun, Oct 19, 2003 at 01:42:34AM -0600, Damien Miller wrote:
> On Sun, 2003-10-19 at 00:47, Peter Gutmann wrote:
>
> > >What was the motive for adding lip service into the document?
> >
> > So that it's possible to claim PGP and X.509 support if anyone's interested in
> > it. It's (I guess) so
On Sun, 2003-10-19 at 00:47, Peter Gutmann wrote:
> >What was the motive for adding lip service into the document?
>
> So that it's possible to claim PGP and X.509 support if anyone's interested in
> it. It's (I guess) something driven mostly by marketing so you can answer
> "Yes" to any questio
Ian Grigg <[EMAIL PROTECTED]> writes:
>So, in reality, the spec does not specify, even if it uses the words? OK, so
>there is no surprise if there is no takeup.
Actually I think the main reason was that there's virtually no interest in this.
>What was the motive for adding lip service into th
Damien Miller <[EMAIL PROTECTED]> writes:
>The SSH protocol supports certificates (X.509 and OpenPGP), though most
>implementations don't.
One of the reason why many implementations may not support it is that the spec
is completely ambiguous as to the data formats being used. For example it
spec
On Fri, 2003-10-17 at 00:58, John S. Denker wrote:
> Tangentially-related point about credentials:
>
> In a previous thread the point was made that
> anonymous or pseudonymous credentials can only
> say positive things. That is, I cannot discredit
> you by giving you a discredential. You'll just
On Mon, 2003-10-13 at 20:27, Ian Grigg wrote:
> The situation is so ludicrously unbalanced, that if
> one really wanted to be serious about this issue,
> instead of dismissing certs out of hand (which would
> be the engineering approach c.f., SSH), one would
> run ADH across the net and wait to se
On 10/16/2003 07:19 PM, David Honig wrote:
>
> it would make sense for the original vendor website (eg Palm)
> to have signed the "MITM" site's cert (palmorder.modusmedia.com),
> not for Verisign to do so. Even better, for Mastercard to have signed
> both Palm and palmorder.modusmedia.com as well.
Hopefully everyone realizes this, but just for the record, I didn't write the
lines apparently attributed to me below -- I was quoting Bruce Schneier.
By the way, I strongly agree with David Honig's point that the wrong entities
are doing the signing.
Regards,
Bryce O'Whielacronx
David Honi
At 01:51 PM 10/16/03 -0400, Bryce O'Whielacronx wrote:
> I doubt it. It's true that VeriSign has certified this
man-in-the-middle
> attack, but no one cares.
Indeed, it would make sense for the original vendor website (eg Palm)
to have signed the "MITM" site's cert (palmorder.modusmedia.
I am very much enjoying the discussion about threat models, web stores, etc.
I'm interested to see a continual influx of spoofed e-mail from e-gold.com in
my inbox, instructing me to click here to verify the safety of my account.
Here is a good rant from Schneier's "Secrets and Lies". From Ch
Ian Grigg <[EMAIL PROTECTED]> writes:
> So to say that ITM is consensus is something
> that is going to have to be established.
Most comsec people I know subscribe to it. I don't
have a study to show it.
> In this case, the ITM was a) agreed upon after
> the fact to fill in the hole
I don't know w
Jon Snader wrote:
> I don't understand this. Let's suppose, for the
> sake of argument, that MitM is impossible. It's
> still trivially easy to make a fake site and harvest
> sensitive information. If we assume (perhaps erroneously)
> that all but the most naive user will check that they
> are
Ian Grigg wrote:
Eric Rescorla wrote:
Ian Grigg <[EMAIL PROTECTED]> writes:
I actually find the Firebird popup vastly more understandable
and helpful.
I'm not sure I can make much of your point,
as I've never heard of nor seen a Firebird?
I believe he's talking about Mozilla Firebird... which is
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 different attacks on the
> > secure sites that I car
On Mon, Oct 13, 2003 at 10:27:45PM -0400, Ian Grigg wrote:
> The situation is so ludicrously unbalanced, that if
> one really wanted to be serious about this issue,
> instead of dismissing certs out of hand (which would
> be the engineering approach c.f., SSH), one would
> run ADH across the net an
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 different attacks on the
> secure sites that I care about. And mostly,
> they don'
Ian Grigg wrote:
Cryptography is a special product, it may
appear to be working, but that isn't really
good enough. Coincidence would lead us to
believe that clear text or ROT13 were good
enough, in the absence of any attackers.
For this reason, we have a process. If the
process is not followed,
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 also think it's
> drawing a stronger contra
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
> > appear to be working, but that isn't really
> > good
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
> appear to be working, but that isn't really
> good enough. Coincidence would lead us to
>
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.
> >
> >
> > Well, that's the sort of confirmation I'
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.
>
>
> Well, that's the sort of confirmation I'm looking
> for. From the documents
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
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 also think it's
drawing a stronger contrast between the real world and the Inte
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
Ian, you and I have discussed this before, so I'll
just make a few comments.
[EMAIL PROTECTED] (Ian Grigg) writes:
> Problem is, it's also wrong. The end systems
> are not secure, and the comms in the middle is
> actually remarkably safe.
>
> (Whoa! Did he say that?) Yep, I surely did: the
> s
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-e
73 matches
Mail list logo
