|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.
|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?
|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.
|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.
|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]
"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.
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.)
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)
(Note the irony of no HTTPS)
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.
Cerberus, is that you?
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.
Thanks for the kind words :-)
|Re: Video and slides for Mill "Memory" talk are up at ootbcomp.com/docs||Noob||10/30/13 5:37 AM|
Ivan Godard wrote:"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:Yeah, I don't care about most of them. The ones that matter turn out
to be small in number.
I think they'll find a way to repair it. I'm an optimist.
Gosh, I thought everyone knew about that one.
|Re: trivial to snoop on https||Noob||11/12/13 1:04 AM|
Mike Stump wrote: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.