30 posts • joined 23 Apr 2018
#5 is completely true; have worked with many Aussies who go into pre-frontal cortex deficient mode when I tell them that govt spying is bad or that the stuff they are proposing will nor work. By using the two trigger words, the govt captures their brains. If you tell them that it is easy to bypass those controls, their usual comeback is, "So you support the terrorists and pedophiles". SMH.
Re: Would this be illegal?
Good point. Compromising the RNG would be bad for the health of ALL crypto. That may be what they may be alluding to. Or push for. They might actually propose Dual_EC_DRBG. Hard for a normal human to test for randomness. I am sure that quantum computing will be put to "good use" when it becomes available. (sarcasm).
Would this be illegal?
Alice and Bob, Aussie and British citizens respectively, each create Elliptical curve key pairs.
Alice and Bob call each other and exchange their public keys.
They then send messages to each other, using ECIES.
Suppose they do rapid ephemeral key exchanges. Would the govt like to keep track of the ephemeral keys too? How many?
Can I generate an ephemeral key every 100 ms or so.
Will the government like to keep track of all the keys?
Programs like Signal: can Dick ban them? How?
Alice’s homeland dictator, Dick, may get overwhelmed.
Linux kernel Spectre V2 defense fingered for massively slowing down unlucky apps on Intel Hyper-Thread CPUs
Intel Hyper threading is an oxymoron anyway
In general I have associated hyperthreading to imply a large number of threads.
Intel uses 2 threads per core and calls it hyper.
I know companies which have built processes with 64 threads per core.
Threads were really meant, in these systems, for computational separation but not memory isolation. For example, you establish a pipeline of processes that data has to flow through to end up at a socket endpoint.
Intel, at some point, may have pushed this as a mkt advantage, selling ‘more’ cpus than they really had.
Are there many applications that get a performance boost IRL from threading? The requirements for cache coherence is extremely tight. I can think of same instruction same data as the basic requirement.
Re: DC and MD are the big winners
1.2B per year subsidy, I.e. 48k per year per employee subsidy for the first 4 years. State + city taxes are roughly 12-15k per year. So payroll taxes doesn’t make up for the loss.
I guess it is corporate welfare.
My bet is Jeff Bezos already knew where he wanted his HQ2 but was trying to get a good bargain.
We asked 100 people to name a backdoored router. You said 'EE's 4GEE HH70'. Our survey says... Top answer!
Re: What would happen
I have seen this argument used many times. The problem is you end up with a Maginot Line effect. Any compromised device on the network can be used to compromise the router. Plus there are ways for JS to initiate a login to the router. So badly implemented browser security can let that happen. The right way to do secure design and implementation is to have security well implemented in ALL components.
Open source processors may be a step
Every cpu security system has been blown wide open. Sometimes it seems that while one part of a cpu team is working hard to secure something, the other part is working hard to undermine the security.
Having managed many sdlc programs, I spent more time going on detective missions where I’d eventually find out a team slipped in a web server, a diagnostic tool, a debug process, etc. without informing us or even documenting it.
And once a device was out in the field there were almost no recalls and the support staff were hooked on to the easy diagnostics (see, no passwords required).
One famous chip vendor’s software team turned off static code analysis because it was giving out too many criticals.
One server code based I scanned had 98,000 criticals. Yup.
In both cases the decision was made to hide everything from my team. Fortunately the CEO stepped in ...
Decoding the Chinese Super Micro super spy-chip super-scandal: What do we know – and who is telling the truth?
Completely plausible. The best proof would be an actual Supermicro board with the spy chip. My only question is, why do it and get a bad rap? My bet is that China has multiple approaches and this got caught. Moreover, China may have realized that the US was aware of the spy chip. So the US went public with it.
Re: Has no one learned the Calxeda lesson?
First sensible response. Maybe there (4) Where is the innovation? (Business, power, performance, management, etc.) should be mentioned more clearly. Not clear if having a totally different architecture works for businesses as it competes with an already x86 humming server ecosystem.
Maybe the authors or inventors haven't been able to articulate the win or they are keeping that under wraps.
Why is it better?
Some of the issues I see are:
1. Software: The Servers including virtualization tools are all standardized around x86 (Intel, AMD). In fact, there is a lot more invested in software than in the HW.
2. Architecture: If the competition is based purely on architecture, the server team will look for highly dedicated (NVIDIA type), or the generalized architecture. A general purpose ARM CPU doesn't buy you anything special. Why not stick to AMD or Intel?
3. Silicon: TSMC may have an advantage in Silicon over Intel but Intel has been pumping out these processors for a long time and beating them on Silicon is an iffy strategy at best. If AMD is having a hard time competing then how can you expect a whole different architecture to win?
1. Watts: Clearly ARM has an advantage when it comes to lower watt CPU but at the higher end, I don't see it being a deal breaker unless the difference is huge. Nothing seems to indicate otherwise.
2. Bottom up: Remember how DEC stole the market from IBM, Sun from DEC, and then Intel from SUN? My believe is that when the majority of the CPU's are ARM systems, which they already are, that they will slowly move into the mainframe.
However, this will take time.
3. Customization: ARM Cpu's can be customized at a faster rate than intel CPU's. ARM CPU's with full blown AI engines, DSP's etc. are very common.
4. Multiple vendors for CPU choices: Unlike Intel or AMD, ARM allows anyone to find a vendor with close enough specs to what they need. If there isn't one then you can have a vendor design and spin one for you. You want one with 3 DSP cores, 2 Neural network cores, etc. and can't find one? Ask a vendor to make you one.
Apple did something like this in-house for their iPhone since Intel can't put everything they want in the CPU at the rate they want it. (plus the power consumption controls ...)
Ultimately ARM will win because of the speed of customization is in months and it will keep on eating into the x86 market. It will, however, take time.
Re: Paranoid AF
Key size is not a measure of crypto strength when the algorithms are different. Enigma had fundamental flaws. It doesn't mean AES doesn't. But we currently don't know of any real ones.
Just to further confuse the issue, AES-128 is stronger than AES-256. AES-256 refers to the key size and not the block size. Bruce Schneider and others pointed out that the number of rounds were too few.
Look up Dan Bernstein's ChaCha, Salsa and Poly series of ciphers and MAC. They have been adopted by many non-government related entities like Google, are being proposed for various RFC's etc.
You are right to be paranoid for a different reason ... quantum crypto attacks are coming.
And badly implemented crypto can lead to side channel attacks. The simplest one is a timing attack ...
Anything can be skewed, TRNG, side channel, extra registers, etc
Tampering with the Silicon: It is probably quite easy to skew the RNG. There goes all ECC. If you are more bold, you might even have a separate pathway to extract secrets (private, symmetric, passwords, etc.). One could also introduce modes where side-channel attacks became easier ...
Question of ethics
We know that FB sold information to Cambridge Analytica which was used to target citizens in various elections around the globe. Both FB and CA made a ton of money. FB was also the platform of choice for Russian trolls. So FB made money from them.
I KNOW I will never do this but as a security professional, I can see an immoral person justifying selling an FB 0 day to a foreign agency and keeping the money for himself. This is a very slippery slope.
Companies are making a ton of money writing bad software and not following SDLC. Shouldn't they be to blame? I can see occasional mistakes slipping through the cracks but a whole slew of them? Every day I hear of flash 0 days. What is up with that? And they are still making money?
Graphics co processors are written for speed
Traditionally, software (and the microcode) written for GPU's is optimized for blindingly fast performance. Don't check for nulls, ranges, types, etc. Just make it run fast. That makes them nice targets for hackers.
Would security experts who have graphics chip knowledge have any insights into the feasibility of being proposed? Would a hacker not target the GPU and take advantage of it?
Isolating the communications is good
In general, IoT attacks occur via normal communications mechanisms and less likely via hardware. In some areas the latter is fairly common; smart meters, set top boxes, etc. It is interesting to see MS isolate the basic communications outside of the main functionality. I wonder how far the isolation goes. Would a driver issue create main kernel issues or is it isolated to the baseband co-processors?
Moreover, how do you isolate higher level communication stack vulnerabilities from the rest of the system?
Maybe someone can educate me.
Also, I think MS intends to open up the VHDL to inspection, right? If not it will be an uphill battle to expose issues.
Key management/Crypto operations
I looked through the ISA and somethings I work with on a regular basis are not there. I guess ISA can be used to implement a secure element? But then, how does it beat a Javacard? The instruction set is too rich for a standard Javacard. Some of the things I do regularly:
1. Secure keys stores including One Time Programmable key stores
2. Secure boot
3. Cryptographic operations
4. Secure elements for operating on sensitive data with sensitive keys. The moment you pul keys into regular memory you are toast; just freeze the DRAM and read it out. Or rely on a software bug.
5. Handling large numbers of keys (i.e. a key-chain).
6. Introduce new cryptographic algorithms.
7. Optimizing energy consumption/peak performance/speed depending upon use-case.
Just protecting address spaces hasn't worked: most applications will need to pull keys from somewhere to use them and therein lies the problem.