[9fans] pathetic

[9fans] pathetic

[ron minnich]

this is a new "innovation" that is being shown at
http://www.newscientist.com/news/news.jsp?id=ns99994696

" Until now, Intel-compatible processors have not been able to distinguish
between sections of memory that contain data and those that contain
program instructions. This has allowed hackers to insert malicious program
instructions in sections of memory that are supposed to contain data only,
and use buffer overflow to overwrite the "pointer" data that tells the
processor which instruction to execute next. Hackers use this to force the
computer to start executing their own code (see graphic).

The new AMD chips prevent this. They separate memory into instruction-only
and data-only sections. If hackers attempt to execute code from the data
section of memory, they will fail. Windows will then detect the attempt
and close the application.

"Buffer overflows are the largest class of software vulnerabilities that
lead to security flaws," says Crispin Cowan, of computer security company
Immunix in Portland, Oregon.
"


golly. seperate I&D space. Which is an idea that is only about 40 or so
years old (Burroughs 5500 ... or am I late even with that).

Actually I'm puzzled anyway as the segment descriptors on x86 have code
and data bits. I'd be willing to be the real issue is that XP uses the
moral equivalent of self-modifying-code, and that now that XP is being
cleaned up they can actually use those bits. But I'm guessing.

I really love the PC world. The only reason they have not claimed
invention of the wheel is that they don't need it yet.


ron

Re: [9fans] pathetic

[Derek Fawcus]

On Wed, Feb 25, 2004 at 08:26:01AM -0700, ron minnich wrote:
> Actually I'm puzzled anyway as the segment descriptors on x86 have code
> and data bits. I'd be willing to be the real issue is that XP uses the
> moral equivalent of self-modifying-code, and that now that XP is being
> cleaned up they can actually use those bits. But I'm guessing.

As I understand it,  this NX bit is at the page level,  and so can alter
a individual 4K page within the linear memory space.  If they used the
segment facility to do this,  the memory space would be non linear and
on the x86 this'd take a massive performance hit (48 bit addresses).

Basically the 386 lost the ability to have non executable address space
when using the paging h/w and trying to present a simple 32 bit address
space.

DF

Re: [9fans] pathetic

[ron minnich]

On Wed, 25 Feb 2004, Derek Fawcus wrote:

> As I understand it,  this NX bit is at the page level,  and so can alter
> a individual 4K page within the linear memory space.  If they used the
> segment facility to do this,  the memory space would be non linear and
> on the x86 this'd take a massive performance hit (48 bit addresses).

well ... on e.g. linux, the segment descriptors are used. Paging on x86 is
in addition to segments. segment are earlier in address translation path
than pages, and they are still there when paging is turned on. It's quite
weird.

I don't see an NX bit in my pentium manual.

ron

Re: [9fans] pathetic

[Aharon Robbins]

In article <Pine.LNX.4.44.0402250822260.9147-100000@maxroach.lanl.gov> Ron Minnich wrote:
>I really love the PC world. The only reason they have not claimed
>invention of the wheel is that they don't need it yet.
>
>ron

Being inventive about the truth is nothing new in the computer world. Note
well IBM's claim to having invented virtual memory.  The guys at that
university in England (Manchester?) had nothing to do with it.

Arnold

Re: [9fans] pathetic

[Derek Fawcus]

On Wed, Feb 25, 2004 at 09:02:45AM -0700, ron minnich wrote:
> On Wed, 25 Feb 2004, Derek Fawcus wrote:
>
> well ... on e.g. linux, the segment descriptors are used. Paging on x86 is

Well the descriptors have to be there,  but they're ususally set for 1:1
mapping (phys == linear).  It used to be that linux used the segments
for proc protection,  then just for the 3G limit,  now I believe they
are set 1:1 and everything done with pages.

> in addition to segments. segment are earlier in address translation path
> than pages, and they are still there when paging is turned on. It's quite
> weird.

err - later.
  Virt => Linear (via paging h/w).  Then Linear => Phys (via segment h/w).

> I don't see an NX bit in my pentium manual.

That's what AMD are supposed to have added.  That's what the whole hoohaw is
about,  they've added a bit somewhere (I'd guess a spare bit from the page
descriptor) such that a page can be non execute.

DF

Re: [9fans] pathetic

[ron minnich]

On Thu, 26 Feb 2004, Derek Fawcus wrote:

> Well the descriptors have to be there,  but they're ususally set for 1:1
> mapping (phys == linear).  It used to be that linux used the segments
> for proc protection,  then just for the 3G limit,  now I believe they
> are set 1:1 and everything done with pages.

yes.

> err - later.
>   Virt => Linear (via paging h/w).  Then Linear => Phys (via segment h/w).

geez did I get this backward again. In my pentium manual it shows it going
the other way.


> That's what AMD are supposed to have added.  That's what the whole
> hoohaw is about, they've added a bit somewhere (I'd guess a spare bit
> from the page descriptor) such that a page can be non execute.

wow, I'm so excited. Oh, wait, I'm not. Oh well. :-)

ron

Re: [9fans] pathetic

[Derek Fawcus]

On Wed, Feb 25, 2004 at 08:45:19PM -0700, ron minnich wrote:
> On Thu, 26 Feb 2004, Derek Fawcus wrote:
> > err - later.
> >   Virt => Linear (via paging h/w).  Then Linear => Phys (via segment h/w).
>
> geez did I get this backward again. In my pentium manual it shows it going
> the other way.

Actually I just thought about it again,  and I got it wrong.  You were
right.

Segmentation,  then paging.  Duh!

DF

Re: [9fans] pathetic

[boyd, rounin]

i'm with you, captain ... i can already smell the napalm burning.

Re: [9fans] pathetic

[boyd, rounin]

the whole 'orrible mess should have consigned to
control µwave ovens, but oh no ...

Re: [9fans] pathetic

[boyd, rounin]

> wow, I'm so excited. Oh,

and i just can't fight it ...

Re: [9fans] pathetic

[Douglas A. Gwyn]

Of course separate I&D doesn't solve buffer overrun problems,
which can still modify the buggy program's data in ways that
the programmer did not plan for.  The attacker gets less
control if he can't force-feed instructions, but he can still
wreak havoc.  If nothing else, he can cause denial of service.

Re: [9fans] pathetic

[Charles Forsyth]

no more compiling-on-the-fly for Java, then?
presumably to avoid eliminating that, there will be a system call
that converts data to code, and if there's a tiny escape hatch ...

Re: [9fans] pathetic

[Geoff Collyer]

No JIT for limbo either.

They'll probably just make the text segment writable and compile
on-the-fly into it.

Re: [9fans] pathetic

[boyd, rounin]

> Oh, but it'll be protected by _lots_ of ACLs:-).

dave, don't get me started on ACLs ...

Re: [9fans] pathetic

[Dave Lukes]

On Thu, 2004-02-26 at 11:32, Charles Forsyth wrote:
> no more compiling-on-the-fly for Java, then?
> presumably to avoid eliminating that, there will be a system call
> that converts data to code, and if there's a tiny escape hatch ...

Oh, but it'll be protected by _lots_ of ACLs:-).

Re: [9fans] pathetic

[dbailey27]

> The attacker gets less
> control if he can't force-feed instructions, but he can still
> wreak havoc.

Not to mention the fact that we don't know how much a given
OS is going to implement the new paging semantics, if at all.

For all we know, Microsoft could use the media hype surrounding
this *miraculous* NE bit to fuel sales for their "professional" line
of server or business platforms. Use a cheaper Windows and you
might get hacked!

Obviously, we still haven't begin to poke at the semantics behind
heap pages being executable. You may overflow a buffer in a NE
page, but can you point to an executable heap page you've previously
written to? There are a million-and-one more scenarios here we've
all hashed over more than once.

This doesn't change a thing but an increase in AMD's stock value,
and Microsoft's later when they implement, then promote it. I've got
no problem with capitalism, but let's look at the facts. This only
alters an attacker's method. It doesn't even make them step in to
uncharted territory.

Don (north_)

Re: [9fans] pathetic

[ron minnich]

On Thu, 26 Feb 2004, Douglas A. Gwyn wrote:

> Of course separate I&D doesn't solve buffer overrun problems,
> which can still modify the buggy program's data in ways that
> the programmer did not plan for.  The attacker gets less
> control if he can't force-feed instructions, but he can still
> wreak havoc.  If nothing else, he can cause denial of service.


That's the best part. They're pumping in 40-year-old ideas, claiming they
are new, and claiming they'll fix something they done.

Still, that's the PC biz for you. Anybody see that picture of Mr. Bill
claiming he will solve the spam problem? quite funny.

ron

Re: [9fans] pathetic

[dbailey27]

> The 1000000 users that aren't running microsoft
> and not using the server can spam each other all they want.

Hey.. wait... 1 million users not running microsoft...
Sure, we'll be able to spam... but will we...? ;-)

Don (north_)

Re: [9fans] pathetic

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

He has the power.  All mail WILL go through a single Miscrosoft
server that will charge everyone 40 cents for each mail message.
Spammers won't be able to afford it.  Problem solved.  Won't
need SPF because there will be only one mail server to read
your mail from and to relay mail.

The 1000000 users that aren't running microsoft
and not using the server can spam each other all they want.

[-- Attachment #2: Type: message/rfc822, Size: 2979 bytes --]

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] pathetic
Date: Thu, 26 Feb 2004 07:36:44 -0700 (MST)
Message-ID: <Pine.LNX.4.44.0402260735370.19744-100000@maxroach.lanl.gov>

On Thu, 26 Feb 2004, Douglas A. Gwyn wrote:

> Of course separate I&D doesn't solve buffer overrun problems,
> which can still modify the buggy program's data in ways that
> the programmer did not plan for.  The attacker gets less
> control if he can't force-feed instructions, but he can still
> wreak havoc.  If nothing else, he can cause denial of service.


That's the best part. They're pumping in 40-year-old ideas, claiming they
are new, and claiming they'll fix something they done.

Still, that's the PC biz for you. Anybody see that picture of Mr. Bill
claiming he will solve the spam problem? quite funny.

ron

Re: [9fans] pathetic

[dbailey27]

[-- Attachment #1: Type: text/plain, Size: 7 bytes --]

URL ?

[-- Attachment #2: Type: message/rfc822, Size: 2883 bytes --]

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] pathetic
Date: Thu, 26 Feb 2004 07:47:33 -0700 (MST)
Message-ID: <Pine.LNX.4.44.0402260746570.19744-100000@maxroach.lanl.gov>

What I want to know is, what was Mr. Bill holding in his hand? It looked
like a USB dongle. It sure got the journalists excited -- that picture was
everywhere.

ron

Re: [9fans] pathetic

[ron minnich]

What I want to know is, what was Mr. Bill holding in his hand? It looked
like a USB dongle. It sure got the journalists excited -- that picture was
everywhere.

ron

Re: [9fans] pathetic

[andrey mirtchovski]

> if you hget then plumb it should look fine in page.

can't I just right-click the url in the acme window of your mail message? :)

OT: i was explaining plumbing to someone whose response was 'oh, just the
same as mime types!'... 'thankfully not', i said...

Re: [9fans] pathetic

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 14 bytes --]

the McGuffin

[-- Attachment #2: Type: message/rfc822, Size: 2434 bytes --]

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] pathetic
Date: Thu, 26 Feb 2004 07:47:33 -0700 (MST)
Message-ID: <Pine.LNX.4.44.0402260746570.19744-100000@maxroach.lanl.gov>

What I want to know is, what was Mr. Bill holding in his hand? It looked
like a USB dongle. It sure got the journalists excited -- that picture was
everywhere.

ron

Re: [9fans] pathetic

[ron minnich]

On Thu, 26 Feb 2004 dbailey27@ameritech.net wrote:

> URL ?
http://www.cnn.com/2004/TECH/biztech/02/25/microsoft.rsa.ap/index.html

It's an "encrypted tag" :-)

ron

Re: [9fans] pathetic

[Dave Lukes]

Mr. Forsyth: you deserve to be remembered for that gag alone.

I sense a parody of "Alfred Hitchcock Presents" in the offing
(in case anyone remembers that show).

Enter Blubbery Bill Gates, stage left
"<wheeze/>This government thought they could live without Microsoft.
 <pant/><wheeze/> ... but they were wrong, as they found
 out to their cost ...<pant/><wheeze/><coronary/>".

	Dave.

On Thu, 2004-02-26 at 15:16, C H Forsyth wrote:
> the McGuffin
>
> ______________________________________________________________________
> From: ron minnich <rminnich@lanl.gov>
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] pathetic
> Date: Thu, 26 Feb 2004 07:47:33 -0700
>
> What I want to know is, what was Mr. Bill holding in his hand? It looked
> like a USB dongle. It sure got the journalists excited -- that picture was
> everywhere.
>
> ron

Re: [9fans] pathetic

[Derek Fawcus]

On Wed, Feb 25, 2004 at 08:26:01AM -0700, ron minnich wrote:
>
> golly. seperate I&D space. Which is an idea that is only about 40 or so
> years old (Burroughs 5500 ... or am I late even with that).

Back to the point...  It would be possible to implement seperate I&D on
existing x86,  but only for a limited set of programs: those without
(certain types of) shared libraries.

Set a code segment to have the required length,  base 0.
Set a decending data segment to the required length,  top ffffffff

Mind one then has to fiddle with segment descriptors,  which may mean
LDTs or  'interesting' set's entries in the GDT.

DF

Re: [9fans] pathetic

[George Michaelson]

On Thu, 26 Feb 2004 08:28:41 -0700 (MST) ron minnich <rminnich@lanl.gov> wrote:

>On Thu, 26 Feb 2004 dbailey27@ameritech.net wrote:
>
>> URL ?
>http://www.cnn.com/2004/TECH/biztech/02/25/microsoft.rsa.ap/index.html
>
>It's an "encrypted tag" :-)
>
>ron

Its SecureID re-worked into a smaller format from what I read elsewhere.

amazing that they will 'buy' this as a M$ invention. I thought people
had single-sign-on worked into microsoft from well before Tivoli and other
IBM product. GSSAPI is so old it has hairs in its nostrils.

Do people still make those gizmos you hold up to the screen, that read the
vertical blanking interval and use that to show the code to be displayed?
they had a nice 'secret agent decoder ring' feel to them.

-George

Re: [9fans] pathetic

[dbailey27]

Just like mine, cool
Mine shut off a couple months ago, though.

I sat mine on my scanner bed and you know the rest:
http://www.blackthailand.net/securid.jpg

I don't think the admin set up MIME types for JFIF, but,
if you hget then plumb it should look fine in page.

Don (north_)

Re: [9fans] pathetic

[dbailey27]

> can't I just right-click the url in the acme window of your mail message? :)

Absolutely! I've turned it off in my acme, however. So, I always forget
that people leave it enabled.

Re: [9fans] pathetic

[ron minnich]

On Fri, 27 Feb 2004, George Michaelson wrote:

> Do people still make those gizmos you hold up to the screen, that read
> the vertical blanking interval and use that to show the code to be
> displayed? they had a nice 'secret agent decoder ring' feel to them.

my guess is they don't work well with LCD :=)

ron

Re: [9fans] SPF+SMTP

[C H Forsyth]

if you thought SPF was over the top, you'll be thrilled by this reference,
which turned up on another email list i'm on.

	http://www.microsoft.com/mscorp/twc/privacy/spam_callerid.mspx

apparently it puts XML into the DNS.  of course.  if they'd made it SOAP,
we could have had the opportunity for viruses spread by DNS.
well, that neatly ties up several recent threads, i think!

Re: [9fans] pathetic

[jmk]

On Thu Feb 26 09:49:03 EST 2004, rminnich@lanl.gov wrote:
> What I want to know is, what was Mr. Bill holding in his hand? It looked
> like a USB dongle. It sure got the journalists excited -- that picture was
> everywhere.
>
> ron

This
	http://news.com.com/2100-1029-5164733.html?tag=nl
gives a little more information. Interesting that Microsoft decided
not to use it internally but opted for a smart-card system. I've
been programming a smart-card recently, they can be useful. Does
anyone have ISO-7816 code for Plan 9?

--jim

Re: [9fans] pathetic

[Richard Miller]

> Does
> anyone have ISO-7816 code for Plan 9?

I've got drivers for some Gemplus reader/writers and a bit
of demo software.  What are you looking for?

-- Richard

Re: [9fans] pathetic

[jmk]

On Thu Feb 26 14:24:46 EST 2004, rm@hamnavoe.com wrote:
> > Does
> > anyone have ISO-7816 code for Plan 9?
>
> I've got drivers for some Gemplus reader/writers and a bit
> of demo software.  What are you looking for?
>
> -- Richard

I've been doing a project (not on Plan 9) where we used some Atmel
chips, the IAR compiler and ACS ACR30-S readers. The Atmel supplied
tools for talking to the reader are terrible and we're looking for
an alternative. What we want to do could be done much easier on
Plan 9 if we had a reader driver. Now that the project is winding
down, we're also thinking on things to do with smart-cards and
Plan 9.

I'm pretty naive about smart-cards.

--jim

Re: [9fans] pathetic

[Richard Miller]

> Now that the project is winding
> down, we're also thinking on things to do with smart-cards and
> Plan 9.

Given what happened the last time s***t c***s were mentioned in
9fans, I suggest we take this conversation off list.

-- Richard

Re: [9fans] pathetic

[boyd, rounin]

> That's the best part. They're pumping in 40-year-old ideas, claiming they
> are new, and claiming they'll fix something they done.

yup

Re: [9fans] pathetic

[boyd, rounin]

> http://www.cnn.com/2004/TECH/biztech/02/25/microsoft.rsa.ap/index.html

<gag>

Re: [9fans] pathetic

[Geoff Collyer]

Just getting most systems to strongly encourage TLS under SMTP would
impose a CPU tax on bulk mailers, though I don't know if it would be
high enough to really slow them down.

Yeah, caller-id for mail: when we find those weasels, oooh, we're
gonna moidalize 'em!  Not.  The NSA has bin Laden's phone number but
they still haven't caught him.

Our current model of e-mail is a dump truck pulling up to your front
door and pouring unfiltered, unsorted mail through your mail slot, in
a vast heap all over your floor, scaring your cats.  I think it would
be improved by moving to a model more like someone knocking at your
door and trying to persuade your butler to let him (the stranger) talk
to you.  If the butler knows the person at the door, he might let him
in, or might toss him out and bar the door.  If the butler doesn't
know the person, he might take the person's calling card, leaving you
to decide if you want to establish contact.  Over time, the butler
comes to know which people you want let through and which you want him
to call the police to remove / shoot / disappear.  Instead of one
trying to drink from a fire-hose (or cement chute!), each message
would result in a negotiation (perhaps very brief!), which is a more
orderly process, the rate of which can be controlled.

Re: [9fans] pathetic

[Dan Moniz]

On 2004-02-26 09:56:39 -0800, jmk@plan9.bell-labs.com said:

[snip]

> This
> 	http://news.com.com/2100-1029-5164733.html?tag=nl
> gives a little more information. Interesting that Microsoft decided
> not to use it internally but opted for a smart-card system. I've
> been programming a smart-card recently, they can be useful. Does
> anyone have ISO-7816 code for Plan 9?

Not I, but you might want to take a look at OpenSC (and possibly 
OpenCT, at the same location) <http://www.opensc.org/>. I have no idea 
how hard it would be to port to Plan 9; I only found it a few days back 
and haven't yet had a chance to look at the code.


-- 
Dan Moniz <dnm@pobox.com> [http://www.pobox.com/~dnm/]

Re: [9fans] pathetic

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

So just take it to its logical connclusion and
make it a pull protocol.  You get a note with a URL
and grab it at your leasure.  This is exactly what MMS
(cell phones that send/rcv pictures) do for reception.  The
message is kept on a server that other phones can pick it
up from.  The notification is sent to the phone via
a short message. Only if sent as email is it wrapped up
as a MIME email containing SMIL instructions, html
text, and jpg pictures.

We could do the same for email, sending a pick up URL,
and some 'secret' for decoding the message or logging
on or whatever.  If you broadcast (like mailing lists)
only the notification goes out.  AOL/Yahoo/etc mail
relays turn into web repositories.  Your mailbox server
can still yank some stuff automagicly if you like the
identity of the sender.  Use TLS on all connections,
if the web can do it, so can email.  Slowing things
down isn't that bad.

It changes the nature of spam somewhat, i.e., it would
become a short message containing nothing but a URL and
a subject.  Oops, that's what most of my spam already is
but at least it means they can't fire and forget, they have
to leave servers up.

And we're now reduced to a previously unsolved problem
with the same solutions.  If we're unwilling to accept
any solution that identifies the sender more than
trusting the From: we're still stuck with our Bayesian
filters etc.  If we're willing to put up with some
caller id, then we have to live with a public key
infrastructure, SPF, or something similar.  I personally
like public keys, just not the infrastructure.  If
someone has introduced themselves to me once and left
a public key, that's good enough for me.

[-- Attachment #2: Type: message/rfc822, Size: 3000 bytes --]

From: Geoff Collyer <geoff@collyer.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] pathetic
Date: Fri, 27 Feb 2004 02:52:15 -0800
Message-ID: <139eb44874bee2237034401996735c24@collyer.net>

Just getting most systems to strongly encourage TLS under SMTP would
impose a CPU tax on bulk mailers, though I don't know if it would be
high enough to really slow them down.

Yeah, caller-id for mail: when we find those weasels, oooh, we're
gonna moidalize 'em!  Not.  The NSA has bin Laden's phone number but
they still haven't caught him.

Our current model of e-mail is a dump truck pulling up to your front
door and pouring unfiltered, unsorted mail through your mail slot, in
a vast heap all over your floor, scaring your cats.  I think it would
be improved by moving to a model more like someone knocking at your
door and trying to persuade your butler to let him (the stranger) talk
to you.  If the butler knows the person at the door, he might let him
in, or might toss him out and bar the door.  If the butler doesn't
know the person, he might take the person's calling card, leaving you
to decide if you want to establish contact.  Over time, the butler
comes to know which people you want let through and which you want him
to call the police to remove / shoot / disappear.  Instead of one
trying to drink from a fire-hose (or cement chute!), each message
would result in a negotiation (perhaps very brief!), which is a more
orderly process, the rate of which can be controlled.

Re: [9fans] pathetic

[Dave Lukes]

> Just getting most systems to strongly encourage TLS under SMTP would
> impose a CPU tax on bulk mailers, though I don't know if it would be
> high enough to really slow them down.

Careful: all you're doing is raising the barrier:
we need to convert the barrier into a wall with a guarded door.

>   The NSA has bin Laden's phone number but
> they still haven't caught him.

They will eventually, by the million monkeys principle:
once they've carpet bombed everywhere that he might be,
they can declare him dead.

> Our current model of e-mail is a dump truck pulling up to your front

Geoff, that is _exactly_ what I needed: a good analogy.

>   If the butler knows the person at the door, he might let him
> in, or might toss him out and bar the door.  If the butler doesn't
> know the person, he might take the person's calling card, leaving you
> to decide if you want to establish contact.

Also,
the caller may have an (original, signed) letter of introduction
from a mutually known third party ...

Cheers,
	Dave.

Re: [9fans] pathetic

[a]

// > The NSA has bin Laden's phone number but
// > they still haven't caught him.

// They will eventually...

my bet is about 3.5 weeks before election day.
ア

Re: [9fans] pathetic

[9nut]

> // > The NSA has bin Laden's phone number but
> // > they still haven't caught him.
>
> // They will eventually...
>
> my bet is about 3.5 weeks before election day.

The odds are better than even. The October Surprise, redux.

Re: [9fans] pathetic

[Lyndon Nerenberg]

--On 2004-2-27 8:07 AM -0500 David Presotto <presotto@closedmind.org>
wrote:

> but at least it means they can't fire and forget, they have
> to leave servers up.

I doubt it. They're just going to modify the behaviour of the Windows
spam agents to support pull instead of push. Incoming connections
through NAT are a no-brainer -- the agent just needs to speak a little
UPNP to the gateway.

--lyndon

Re: [9fans] pathetic

[Tristan Seligmann]

On Fri, Feb 27, 2004 at 08:07:56 -0500, David Presotto wrote:
> So just take it to its logical connclusion and
> make it a pull protocol.  You get a note with a URL

This is what djb's "Internet Mail 2000" proposal describes:

    http://cr.yp.to/im2000.html

mithrandi

Re: [9fans] pathetic

[boyd, rounin]

> // > The NSA has bin Laden's phone number but
> // > they still haven't caught him.

well, i have my NSA baseball cap on ;)

Re: [9fans] pathetic

[Geoff Collyer]

I'd be happy to accept public keys for authentication, but don't yet
have good ideas for how to get people to generate key pairs nor how to
distribute their public keys.  PGP hasn't taken over the world (though
it might do a little better if Apple were to integrate it with their
mail client seamlessly).

I'm willing to trust the remote IP address of a TCP connection as
identification.  The tuple of (remote IP address, claimed From:
address, recipient) should be enough to decide if I want a message,
especially if software doesn't have to decide accept-or-reject while
the sender is connected but has the third option of saying `hold it
until the recipient decides (or 10 days have elapsed)'.  For example,
I know that mail from 9fans-admin@cse.psu.edu *or* to
geoff.9fans@collyer.net should come from 130.203.4.6
(mail.cse.psu.edu) only.

Re: [9fans] pathetic

[boyd, rounin]

> my bet is about 3.5 weeks before election day.

i'm about to swaps hats [baseball caps] to ENIGMA.

Re: [9fans] pathetic

[Vin McLellan]

Ron Minnich <rminnich@lanl.gov> asked:

>What I want to know is, what was Mr. Bill holding in his hand? 

http://www.cnn.com/2004/TECH/biztech/02/25/microsoft.rsa.ap/index.html

>It sure got the journalists excited -- that picture was everywhere.

	The AP photo slug described it an "encrypted tag" -- whatever that is
-- but Ron said "it looked like a USB dongle."

	George Michaelson <ggm@apnic.net> reported:

.> Its SecureID re-worked into a smaller format from what I read 
.> elsewhere.

	Close but not quite accurate. It's the classic RSA SecurID key fob,
the same size as its been for the past six or seven years. Maybe like
many things -- markets, competitors, nations -- SecurIDs look smaller
when they are lie in the palm of Bill G;-)

	RSA's SecurID, for those who don't know, is a hand-held
authentication token that uses the AES cipher to hash "Current Time,"
and a 128-bit secret, to generate (and continuously display in a small
LCD) a series of 6-8 digit pseudo-random tokencodes that flip over
every 60 seconds. (One-time passwords like this are typically used as
evidence of "something held," and are paired with a user-memorized PIN
or password, "something known," for two-factor authentication -- the
classical definition of "strong authentication.")

	The key fob has been the most popular form-factor for the SecurID for
years, but many people -- including perhaps the AP photo editor --
still picture the SecurID as the credit card-size device that was its
most common "form-factor" through the late 1980s and early 1990s.

	Today, however, there are 7 or 8 different SecurID form-factors,
including the SecurID card and key fob, but also including software
modules that can be downloaded for Palm Pilots, Pocket PCs,
Blackberries, Nokia and Sony/Ericsson mobile phones, as well as
desktop PCs (where the physical security justifies the added risk.)

        There is a whole spectrum of greater and lesser security
associated with the implementations in these various form factors,
obviously, but market demand continues to push SecurID functionality
into devices the user already carries, and the SecurID's
trustworthiness ultimately boils down to RSA's cryptographic grip on
the 128-bit seed, the AES-protected shared secret.

	I'll be surprised if RSA, for which I am a consultant, doesn't
finally deliver, in '04, the SecurID wristwatch that SecurID inventor
Ken Weiss was talking about in '87. Guessing that the SecurID is
shrinking was smart, George -- but the SecurID widget Bill G was
waving around was just a standard SecurID fob.

        You guys are obviously correct to note that increased the
rigor of the user authentication mechanism won't preclude attacks on
the underlying Windows infrastructure, but -- by extending SecurID to
the off-line PCs (a la S/key), and installing ACE/Agents (to demand
two-factor authentication) at the domain controllers and terminal
servers -- MS will greatly enhance the grandularity of the IT audit
record. In a marketplace increasingly shaped by HIPAA, Sarbane Oxley,
and world-wide privacy regs, that itself has high value in corporate
IT.

        Suerte,
                _Vin