Video and slides for Mill "Memory" talk are up at ootbcomp.com/docs

Showing 1-12 of 12 messages
Video and slides for Mill "Memory" talk are up at ootbcomp.com/docs Ivan Godard 10/23/13 7:33 PM
The video is for the talk only. The discussion portion (longer than he
talk) is in edit and will be posted later.

Ivan
Re: Video and slides for Mill "Memory" talk are up at ootbcomp.com/docs MitchAlsup 10/23/13 9:13 PM
The sever requires a login and a password.
What would mine be?

Mitch
Re: Video and slides for Mill "Memory" talk are up at ootbcomp.com/docs Ivan Godard 10/23/13 11:54 PM
Use http not https.

Ivan
Re: Video and slides for Mill "Memory" talk are up at ootbcomp.com/docs Noob 10/24/13 1:09 AM
Ivan Godard wrote:

> Use http not https.

But the NSA is watching!

Re: Video and slides for Mill "Memory" talk are up at ootbcomp.com/docs George Neuner 10/24/13 5:55 PM
Doesn't matter. They have a key to the patent office.
Re: Video and slides for Mill "Memory" talk are up at ootbcomp.com/docs Jean-Marc Bourguet 10/27/13 6:32 AM
Ivan Godard <iv...@ootbcomp.com> writes:

Am I right to think that that you have to unroll loops more than an OO
processor for your strategy to work there?  And I wonder if your
specializer do the unrolling as my guess is that the optimal amount of
unrolling will depend on the details that the specializer is supposed
to take care of.

Yours,

--
Jean-Marc
Re: Video and slides for Mill "Memory" talk are up at ootbcomp.com/docs Ivan Godard 10/27/13 12:36 PM
No, we generally do not unroll at all. Software-pipelines on a Mill are
the subject of a future talk, but the result is:

1) We unroll only when two (or more) iterations will fit in a single
instruction; high-end Mills are wide enough for that to happen, e.g.
"A[i] = B[i] * C[i]" on a Gold unrolls 4X to use the four FPU units.

2) Pipelines have no prologue and no epilogue

3) Many things that preclude pipelining on other machines are no problem
on a Mill, including embedded control flow.

The deferred load operations described in the Memory talk are for random
memory accesses. As the talk says, sequences of related memory
operations, such as walking an array in a loop, are prefetch problems,
not load problems, and what we do will be described in another talk,
after the relevant patents are in.
Re: Video and slides for Mill "Memory" talk are up at ootbcomp.com/docs Mike Stump 10/29/13 11:15 AM
You do know that is trivial to snoop on https, right?  First, they can
steal or demand by law the server key.  That assumes they don't
already have a collection of keys already.  The chance they don't have
a collection is 0, the only remaining question is, how large is their
pool?  Second, the client can have an untrustworthy CA stuck into it.
Your ability to monitor and decide which CA is untrustworthy is near
about zero.  Next, brute forcing a weak CA, are you certain that no CA
chain can be brute forced?  Hard to know.

Also, keep in mind, they can impersonate the automatic update my
software servers, get new code loaded on the the system and then
update the ssl code or the CAs or any other software as they want.
Have you ever updated your software, has the server you want to
communicate with ever updated their software?  If yes, would you know
if you have ever pulled down an update that was not genuine.  Oh, and
if you say no to both, then, surely you have lots of nice security
holes that remain unpatched.  Catch 22.

Now, all that supposes that the company (or a CA) doesn't just want to
trust the NSA and cooperate with them.  What evidence do we have for
that?  Can we believe it, if so, why?

Now, if you're a student of history, you will know that companies
already voluntarily cooperate with the NSA in ways that are not
mandated by law.  Second, they likely have already impersonated update
servers.  Third, others have already hacked genuine CAs. Fourth,
others have already hacked weak crypto CAs.

The good news, it is unlikely that they care about you.  And, if they
do, good luck on that.
trivial to snoop on https Noob 10/30/13 4:54 AM
[Cross-posted to comp.arch where the discussion started
and sci.crypt where it is topical]

Mike Stump wrote:

> You do know that is trivial to snoop on https, right?

"Lasciate ogne speranza, voi ch'intrate"

or, in other words,

"If the crypto is useless, why bother using any?"

The answer, of course, is that the premise is flawed, the
math is solid, people should use *more* crypto, not less.
=> 2048-bit RSA keys with PFS protocols.

> First, they can steal or demand by law the server key.

There are probably 10-100 million HTTP websites on the
intarwebz, many of them NOT hosted in a police-state.
Are you suggesting that the NSA is able to crack several
millions websites, while remaining undetected? (If so, you
give them too much credit, e.g. they were identified in the
Freedom Hosting take-down.)

> That assumes they don't
> already have a collection of keys already.  The chance they don't have
> a collection is 0, the only remaining question is, how large is their
> pool?  Second, the client can have an untrustworthy CA stuck into it.
> Your ability to monitor and decide which CA is untrustworthy is near
> about zero.  Next, brute forcing a weak CA, are you certain that no CA
> chain can be brute forced?  Hard to know.

Indeed, the CA security-model seems broken beyond repair.
People are working to replace it (certificate pinning,
TACK, Convergence, Perspectives, Certificate Patrol,
via DNSSEC, etc)

http://tack.io/
http://convergence.io/
http://perspectives-project.org/
(Note the irony of no HTTPS)

> Also, keep in mind, they can impersonate the automatic update my
> software servers,

Right. Then drown in the Streisand-effect tsunami when they
are inevitably found out. You know, passive surveillance is
much, MUCH, *MUCH* easier to pull off than active tampering.

> get new code loaded on the the system and then
> update the ssl code or the CAs or any other software as they want.
> Have you ever updated your software, has the server you want to
> communicate with ever updated their software?  If yes, would you know
> if you have ever pulled down an update that was not genuine.  Oh, and
> if you say no to both, then, surely you have lots of nice security
> holes that remain unpatched.  Catch 22.

Cerberus, is that you?

> Now, all that supposes that the company (or a CA) doesn't just want to
> trust the NSA and cooperate with them.  What evidence do we have for
> that?  Can we believe it, if so, why?

It's a shame US companies have wasted all the trust and goodwill
they had built in the past two decades. I guess this will help
non-US based players to catch up, which is a good thing(TM)
because the USofA has too much control over the internet.

> Now, if you're a student of history, you will know that companies
> already voluntarily cooperate with the NSA in ways that are not
> mandated by law.
> Second, they likely have already impersonated update servers.

Citation please.

> Third, others have already hacked genuine CAs. Fourth,
> others have already hacked weak crypto CAs.
>
> The good news, it is unlikely that they care about you.  And, if they
> do, good luck on that.

Thanks for the kind words :-)

Regards.

Re: Video and slides for Mill "Memory" talk are up at ootbcomp.com/docs Noob 10/30/13 5:37 AM
Ivan Godard wrote:

> and what we do will be described in another talk, after the relevant
> patents are in.

"I love the smell of patents in the morning. You know, one time
we had patents filed, for 12 hours."

Re: trivial to snoop on https Mike Stump 11/11/13 6:30 PM
In article <5270f380$0$2290$426a...@news.free.fr>,
Noob  <root@localhost> wrote:
>There are probably 10-100 million HTTP websites on the
>intarwebz, many of them NOT hosted in a police-state.

Yeah, I don't care about most of them.  The ones that matter turn out
to be small in number.

>Indeed, the CA security-model seems broken beyond repair.

I think they'll find a way to repair it.  I'm an optimist.

>> Now, if you're a student of history, you will know that companies
>> already voluntarily cooperate with the NSA in ways that are not
>> mandated by law.
>> Second, they likely have already impersonated update servers.
>
>Citation please.

http://nakedsecurity.sophos.com/2012/06/04/flame-malware-used-man-in-the-middle-attack-against-windows-update/

Gosh, I thought everyone knew about that one.
Re: trivial to snoop on https Noob 11/12/13 1:04 AM
Mike Stump wrote:

> http://nakedsecurity.sophos.com/2012/06/04/flame-malware-used-man-in-the-middle-attack-against-windows-update/
>
> Gosh, I thought everyone knew about that one.

Ah yes, I read about the vulnerability, but didn't know it
had been actively exploited, much less by the USgov. Thanks
for the pointer.