Hacker News new | past | comments | ask | show | jobs | submit | jasonmoo's comments login

Plug alert: I am working with a company that's building a full representation of the Sanctum system using custom extensions of RISC-V (https://eprint.iacr.org/2015/564.pdf). There are critical features like root of trust key and entropy generation, and cache isolation that are missing from the vanilla RISC-V keystone approach. It offers a measure of security worth having but we're taking it all the way. We're working with MIT prof Srini Devadas. You can read more about it here if you're interested: https://medium.com/gradient-tech/announcing-gradient-crypto-...

Also we're hiring! https://www.gradient-tech.co/jobs


That's great - will it be open sourced in some way? SiFive demonstrated RISC-V secure boot using (closed) Rambus IP for the RoT.


Some version at least will be yes. RE: RoT + RISV-V, cache isolation appears missing here, so sidechannel attacks using cache timing and other methods still work


Awesome! It was unclear to me where the Rambus IP began and SiFive's core took over in the demo.

Keystone using existing RISC-V extensions is exciting to see, but it's frustrating that the Hack a Day article seems to confound where it begins and ends (at least today). The Keystone presentation notes that the RoT is derived from Sanctum and their docs indicate that you need to bring your own entropy and key storage, neither of which are made clear in the blog post.


It looks like a ride-sharing service logo.


I've always wanted to do more with Sikuli. I could see it working well for this.


microservices. the struggle is real.


Overuse of microservices is definitely a valid case of bad design.


Sure but you can easily compose 4 services into a single representation and still have an appropriate amount of decoupling. Think of a dashboard.

graphql points toward this

https://github.com/facebook/graphql


You can, but the pertinent question is whether you should. Microservices help with scaling endpoints that become bottlenecks but introducing them before they become necessary suffers from many of the common problems associated with premature optimisation.


It's interesting I think having an understanding of the history of javascript concurrency is almost a prerequisite to using it correctly. I wonder how new people approaching the language for the first time find it.


I find two camps: 1. those who need to produce backwards-compatible code, avoiding or not thinking about new features 2. those who can/want to use new features

Camp 1 has the problem of continuously importing kitchen sinks instead of polyfills, which would allow getting into camp 2.

Camp 2 is essentially a luxury of time, thus rare. It already requires mental commitment, which may be scarce after a day of battling bugs for IE.


I think that as a beginner you can get far with async/await without truly understanding it. I also think that at some time the abstractions will leak and your head will spin madly.


I wrote the script in question and actually used a simple shannon entropy value. (http://codereview.stackexchange.com/questions/868/calculatin...). It worked well enough help rule out several problem spaces.


Would you mind posting the script? I'd love to run it against our codebase and see what it comes up with.

It might be a fun thing to open source as part of a "I've inherited a project, what now?" toolkit that helps you decide what to fix.


Sure. It's a simple tool but the concept could be augmented toward something like the scenario you described.

https://gist.github.com/jasonmoo/06691c8fea09b62aa35235fc93e...


IIRC Instagram released a plugin for Bandit (the OpenStack static analyzer for Python) that does this.


This is a great company. Golang developers welcome too!


Had that in mind when I named it.


go max!


This is great! Here's a demo of the full set to illustrate your point more fully.

http://play.golang.org/p/T1eJ4prBHM


Missing 9 and 6.

mirror pairs

(1) 0001/1000 (8)

(2) 0010/0100 (4)

(3) 0011/1100 (C)

(5) 0101/1010 (A)

(7) 0111/1110 (E)

(B) 1011/1101 (D)

(0) 0000/1111 (F)

Program exited.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: