Re: First sighting of real-life AFM data retrieval? [¡PING! Peter G...]

2008-09-19 Thread Peter Gutmann
Dave Korn [EMAIL PROTECTED] writes:
  After getting a search warrant and confiscating his hard drive,
investigators were forced to scour through its remains using an electron
microscope, and the price of $100,000 per pass.  

The claim comes from Robert Schperberg, forensics lead for Chevron, [ ... ]
at the MIS Training Institute's IT Security World conference in San
Francisco, and is otherwise unverified.  I haven't been able to get hold of
any kind of transcript, so thus far it only has the status of Something
someone said when giving a talk at a conference.

Whatever it is it seems to have been garbled beyond recognition, if they were
just looking for straight evidence they'd be using Encase, if they were
looking for data in erase bands (assuming the drive was old enough to still
feature them, they'd be hard to find in any modern drive) they'd be using
something like a magnetic force microscope which is a scanning probe
microscope, or a magnetic force scanning tunneling microscope, and in either
case I doubt you could read perpendicularly-recorded EPRML data just by
staring at it.  So I don't think it's possible to draw any conclusions from
this data.


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: once more, with feeling.

2008-09-19 Thread Peter Gutmann

Any evidence of that?  [People buying certs using stolen credit cards]

I don't know if anyone tracks the exact count (apart from the 2005 figure of
(at least) 450 recorded incidents of secure phishing) but every now and then
you get reports of particular ones that stand out, e.g. the Sunbelt discussion
of the Gromozon distributors signing their malware, (the cert
purchase was eventually traced back to a victim in Florida)... sorry, I don't
catalogue them all, just watch them drift by every now and then and that one
came to mind.  In fact didn't our esteemed moderator mention running into one
of these via spammed email just a few months back?

In any case with the assistance of services like for the
ID and any one of the incorporation brokers operating in the US (I
particularly like the appropriately-named, you can do it for far less via US
brokers but then if you're paying with soemone else's credit card cost isn't
really an issue) how long do you think it'd take to create an official US
corporation that qualifies for an EV cert?  I think the main reason we haven't
seen more of this is:

- There's no need for it, usability evaluation tests have shown that EV certs
  have no effect on security so there's no point in going to the trouble
  (cybercrooks are cheapskates).

- It's much easier to use an exploit toolkit like MPACK or whatever to hit an
  EV-certified site for a genuine organisation than it is to bother with your
  own EV cert.  Since an EV cert only says that the CA did a little bit more
  than almost no checking at all of credentials but doesn't tell you anything
  about the site, the easiest way to get an EV cert is to use someone else's
  (AV vendors report peaks of up to 10,000 fresh malware infection sites via
  legit compromised servers a day, which is bad news for the only enter your
  credit card details on sites you trust education effort).


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Cookie Monster

2008-09-19 Thread James A. Donald

EMC IMAP wrote:
 Yet another web attack:

 My own conclusion from this:  This is yet another indication that
 the whole browser authentication model is irretrievably broken. It's
 just way too complex, with way too many moving parts which can
 interact in dangerous ways.  The list of requirements for a safe
 Web application - even just based on attacks known today - is so
 long that no one can remember them all, much less check any
 substantial Web application to see if it follows them.

 We need a better approach.

As I posted earlier:

SSL/TLS does not supply secure logon and sessions, because it does not
know what a session or a login is.   Instead http+tls provides a pile
of matchsticks and glue with which the website server can implement
something that kind of sort of mostly behaves rather like logins and

It should have been obvious that everything really important relates
to logins and sessions and that the rest can be treated as a login by
anon 37283 with the null password, and that therefore the
cryptography *and* *the* *browser* *user* *interface* needs to
implement logins and sessions.

It should have been obvious that logging in on the web page was going
to lead to the phishing disaster - that people should login on a
trusted path from the browser chrome.

The user login status should be displayed in the chrome on every
logged in web page, and the server has to know that the user knows his
login status, has to know the login status not only of the user, but
of the web page that the user has clicked on that generated this
request to this server.

The state of being logged in should guarantee privacy and authenticity
- that only the client and the server can know what they are
communicating, and that no one else should be able to pass himself off
as client or server, or modify their communications

Everything should have been written around the user concepts of
logging in  a logged in page, and logging out, and should have
made those user concepts real, made them into pages with appropriate
built in cryptographic behaviors, rather than providing capabilities
that could potentially be used to make pages behave like that.

The user concept of logged in has to be real rather than
superficially simulated by server side code

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Cookie Monster

2008-09-19 Thread Leichter, Jerry
On Fri, 19 Sep 2008, Barney Wolff wrote:

| Date: Fri, 19 Sep 2008 01:54:42 -0400
| From: Barney Wolff [EMAIL PROTECTED]
| Cc: Cryptography
| Subject: Re: Cookie Monster
| On Wed, Sep 17, 2008 at 06:39:54PM -0400, EMC IMAP wrote:
|  Yet another web attack:
|  As I understand the attack, it's this:  Cookies can be marked Secure.   
|  A Secure cookie can only be returned over an HTTPS session.  An cookie  
|  not marked Secure can be returned over any session.  So:  If a site  
|  puts security-sensitive data into a non-Secure cookie, an attacker who  
|  can spoof DNS or otherwise grab sessions can send a HTTP page  
|  allegedly from the site that set the cookie asking that it be returned  
|  - and it will be.
| Why on earth would anyone put security-sensitive data in a cookie,
| unencrypted?  It's the server talking to itself or its siblings, after
| all, and it's vulnerable to attack on the client's machine.
a)  It depends on who you think it has to be secure against.  Typical
reasoning:  If it's effectively the *client's* information, why/from
whom do I need to protect it while it's on the *client's* machine?
After all, it can only be seen by the client and me.

b)  The way this attack is actually likely to be used is to steal a
logged-in session.  If I have the cookie, and can MITM the stream
to the server, I can act within the logged-in session.  I don't
need to be able to decrypt the cookied - the real client has no
need to (but in fact there isn't much point in encrypting, while at
rest, the nonce that identifies the logged-in session.)

I put logged-in session in quotes in agreement with James Donald's
message on this subject.

-- Jerry

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Lava lamp random number generator made useful?

2008-09-19 Thread Jerry Leichter
The Lava Lamp Random Number generator (at  
generates true random numbers from the images of a couple of lava  
lamps.  Of course, as a source of randomness for cryptographic  
purposes, it's useless because it's visible to everyone (though I  
suppose it might be used for Rabin's beacons).

At ThinkGeek, you can now, for only $6.99, buy yourself a USB-powered  
mini lava lamp (see   
All you need is some way to watch the thing - perhaps a USB camera -  
and some software to extract random bits.  (This isn't *really* a lava  
lamp - the lamp is filled with a fluid containing many small  
reflective plastic chips, lit from below by a small incandescent bulb  
which also generates the heat that keeps the fluid circulating.  From  
any given vantage point, you get flashes as one of the plastic chips  
gets into just the right position to give you a reflected view of the  
bulb.  These should be pretty easy to extract, and should be quite   
random.  Based on observation, the bit rate won't be very high - a bit  
every couple of seconds - though perhaps you can use cameras at a  
couple of vantage points.  Still, worth it for the bragging rights.)

An alternative, also at ThinkGeek, is a USB-powered Plasma Ball (at 
.  The arc discharges should be even easier to convert into a  
bitstream, though it's probably a more biased source than the lava  
lamp, so will need more post-processing.

-- Jerry

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]