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

[Ivan Godard]

The video is for the talk only. The discussion portion (longer than he
talk) is in edit and will be posted later.

Ivan

[MitchAlsup]

The sever requires a login and a password.
What would mine be?

Mitch

[Ivan Godard]

Use http not https.

Ivan

[Noob]

Ivan Godard wrote:

> Use http not https.

But the NSA is watching!

[George Neuner]

Doesn't matter. They have a key to the patent office.

[Jean-Marc Bourguet]

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

[Ivan Godard]

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.

[Mike Stump]

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.

[Noob]

[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.

[Noob]

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."

[Mike Stump]

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.

[Noob]

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.