Posts by MJB7 568 publicly visible posts • joined 27 Nov 2013
The boring answer is almost certainly electron beams. Cutting very fine details with an electron beam has been possible for ages (I think that's how existing masks are made). The problem for chip lithography is that electron beam is _slow_ (you only cut one bit at a time). An optical mask can cover the whole chip in one go.
> I'd think even a half-competent government can probably build their own data centers and go fully open source for about the same price.
Do you mean "a government which is half-way along the list of governments sorted by competency"? Looking at the number of government-based IT disasters, I really doubt it.
Or do you mean "a government which is half-way to being fully competent" ? I'm not sure there are any of those.
> Can someone explain to me how a hyper-velocity impact with a satellite fails, enough to break chunks off, does not result is a significant effect on the orbit?
Not sure what the actual numbers are here, but:
1 tonne (1 Mg) stage in orbit.
10g "thing" smacks into the stage at 10,000 m/s relative to the orbiting stage. That's quite a bang, and could easily crack something off, but it changes the momentum by 100,000 gm/s - which is a change in velocity of 10cm/second. Typical LEO orbital velocities are about 8,000 m/s (which is why I chose 10,000).
Net result: The orbit changed (of course), but not significantly. A 10kg bullet would make more of a difference - but it would still be pretty small.
> Passwords salted and hashed, miscreants aren't going to be able to do much with that
Depends _how_ it is hashed. If it PBKDF2 with 1000 iterations of SHA1, it'll take longer to download the data than to find if the password is one of the top 1000 passwords.
If they are following OWASP recommendations and using Argon2id with a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism then I agree. However "following OWASP" probably isn't the way to bet in this case.
... but I do agree that they deserve plaudits for being upfront about the situation.
I wonder if I see a different UI (connecting to amazon.de). The last couple of times I have signed up for a free 3-months Prime trial, I have found it really quite straightforward to cancel my Prime membership.
I also like the fact that I can sign up, place the order, and then cancel it - but it still lasts until my three months is up.
Err.
1. SMS is the _least_ secure MFA option (by a substantial margin). Use a TOTP generator instead.
2. There are certainly a substantial number of people in my office who won't install a a custom app to act as a MFA token on their own phones. I don't _know_ whether they would accept texts - but I wouldn't want to bet on it!
Minor nit: I _think_ even Alabama now insists on children being at least 14 before marrying.
A 13yo legally married to an adult in one of the United States is probably legally married in the UK. They just can't have sex in the UK (and the adult is at risk of being prosecuted for having sex in America).
The worst bug I ever came across was a memory corruption bug that only occurred if the username had an odd number of characters. The programmer who kept encountering the bug did. The programmer who was trying to debug it had an even number of characters in their user name. That was _days_ of fun!
(This was before valgrind.)
Standard practise in Germany. Don't forget, everything is on a series of 16A radials, rather than ring circuits (and neither appliances, nor lights, have fuses).
The safety and cost trade-offs between the UK and European systems are complex - but neither is per-se dangerous.
It is perfectly possible to write secure systems with RSA. What's wrong with it, is that it is slower to sign/encrypt than a corresponding EC algorithm, and it is _much_ slower to generate a new key. That last point matters if each participant generates a new keypair for each message (as they should), and only uses the persistent key pair for authenticity.
There _is_ a theoretical point that because quantum computers break asymmetric cryptography in a completely different way to classical computers, a quantum computer that can break RSA-3076 will need about 12 times as many qbits as one that can break NIST-P256. If quantum computers develop at something like Moore's Law (a _big_ if), that gives RSA-3076 about a decade advantage over P256.
The Cambridge Maths Tripos Part III is a fourth year of university which prepares students for a career in mathematical research. The questions on the exam paper are often of the form "Prove or counter-example the following proposition". Legend has it that the exam setters don't always know the answer.
You are referring to Zaha Hadid. Coincidentally I was in her fire-station this morning. It was a fire station for a big factory - run by Vitra, which makes designer furniture and is famous for having a factory site with examples of amazing architecture. The fire station is a fabulous bit of a sculpture, but is indeed useless as a fire station.
I don't think that is what the problem was.
They should have dispatched the engineer _straight away_, in case the on-site engineer was needed. Then they should have diagnosed and fixed the problem remotely (and then told the engineer to come back).
The alternative is wait an extra half an hour while they diagnose the problem and realize they need an on-site engineer. That's half an hour wasted.
Security is difficult, but the one thing you _don't_ need in your list is "an understanding of the maths of cryptograph" (let alone a deep understanding). What you _do_ need, is to understand what promises a cryptographic primitive makes and what promises it _doesn't_ make.
As an example, I know almost nothing about AES or 3DES beyond "stick a secret and a key in here, magic happens, and ciphertext appears out here". However I _do_ know that these only promise that an attacker cannot determine the secret given the ciphertext. What they don't promise is that the attacker can't modify the ciphertext in a way which modifies the secret. For that, you need an AEAD scheme like AES-GCM or AES-CBC + HMAC.
The materials under discussion are described as "ionic liquid salts". If it's a liquid which is full of ions, it is hard to see how it could _not_ be a conductor
(But as they've already done one impossible thing before breakfast, there's no obvious reason they shouldn't do another.)
The trouble with having the plug cast into the body, is when you go abroad regularly. With an IEC lead I can take my charger and the right IEC lead and I'm good. With a moulded-in plug, I need an adaptor (which in Switzerland for example will obstruct both the other sockets in the outlet).
RSA 1024 is only acceptable for historic protocols. It should not be used today. RSA 2048 is perfectly acceptable today, but for longer term security, you need RSA 4096 or higher.
Key generation _is_ slow for RSA. The hardware security module my employer makes can take 15 minutes to generate an RSA16384, and it's got a relatively beefy processor. An IoT device is going to take a while to generate RSA2048 (not to mention the problem of "where does it get the entropy from") - but it doesn't have to do that for every message.
Firstly, you keep claiming that Alice and Bob can communicate securely "with no transmitted keys and no public keys at all." but you refer to Diffie Hellman.
In the Diffie-Hellman protocol:
- Alice generates a secret key a, and a public key A = e**a
- Bob generate corresponding b and B.
- Alice TRANSMITS her PUBLIC KEY (A) to Bob
- Bob TRANSMITS his PUBLIC KEY (B) to Alice
- Alice computers B**a == (e**b)**a == e**ab;
- Bob computes A**b and they have a shared secret e**ab which they can use to encrypt data.
(Beware: the above is a gross simplification. Do not use this to implement DH.)
Secondly, you have also missed the point that this is _storage_ encryption. Communication (data in transit) can use ephemeral keys, but data-at-rest must be encrypted by keys that persist until the data is no longer required.
And I haven't even _started_ on the issue that DH is completely unauthenticated, so Alice has no way of knowing she is communicating with Bob and not Eve.
"you're a terrible password generator" - this is true. So don't generate the password yourself. Both Bitwarden and diceware will let you generate a cryptographically secure passphrase which works just fine.
Reading between the lines though, it is disappointing to see that Bitwarden don't use a secret from the second factor to decrypt the vault.
> the keys used for E2EE are persistent somewhere [on the service provider's network]
Only if the software is badly designed (as Threema seems to have been). When I was working for a company providing E2EE mobile comms (based in Zürich as it happens), the private keys never left the phone. That's easy to arrange.
The story is better than that.
The satellite was in orbit before BAS started taking measurements. However the graphs displayed to end users used preprocessed data, and one of the preprocessing steps was to replace obviously absurd values (because they were too small) with a sensible minimum value.
Oops.
Jonathan Shanklin on the other hand knew almost nothing about the ozone layer, so just blindly plotted the observed values.
Footnote: There are many things he knows almost nothing about, but I don't think "the ozone layer" is still one of them.
Scott Aaronson is not a mouthpiece of the American government, and he's not the only one pouring cold water on this claim. Lots of people are working on post-quantum crypto, but nobody is particularly rushing to roll it out. Apart from anything else, you don't want to discover you've implemented SIDH and then somebody comes along and breaks it over a weekend.
3nm is FIFTEEN silicon atoms. I realize that these lengths are no longer the actual size of the transistor, but even if its the radius of the curves, we are getting to the point where we can no longer consider silicon as a continuum.
Also, a cube 3nm across has a volume of 27e-27 m3. Wikipedia says dopant concentration runs up to 10**18 per cc which is 10**24 m3 ... which implies such a cube has zero dopant in it!
There are various ways to break a cryptographic hash function. The first is to generate two different messages with the same hash value (a collision attack). This is the easiest break for the attacker, and SHA-1 has been broken like this for some time, and has not been allowed by NIST for uses where this matters for some time either.
The next break is: given a specific message (defender controlled), find another (different) message with the same hash value (a pre-image attack). Not only has SHA-1 not been publicly broken like this, neither has MD5. If you have an expert cryptographer on hand†, they can advise you whether your application is vulnerable to a collision attack, or whether it needs a pre-image attack to break it. If it needs a pre-image attack, there is no need to panic (but move away from SHA-1 at your earliest convenience).
† Don't look at me, I just use a few handy rules of thumb when doing crypto - one of which is "don't use SHA-1".
I can see why IT support might seem like a sensible thing to outsource. Instead of having one person who needs to be able to handle DB admin, network configuration, hardware wrangling, etc (and who can't go on holiday), you can have a share of a full-time DBA, and a networking guru, and a hardware experts - and with cover so you don't have to worry about holidays or sickness.
In practise of course, it never seems to work. I remember when I foolishly deleted a file and asked IT (a three man in-house team) to restore a copy from backup if possible (if not, I could regenerate from scratch). Three days later I got an apology for having taken so long - they had been struggling with sickness in the team. AT THE SAME TIME, my customer had corruption in their SourceSafe database. The only fix was a restore from backup. Until this was sorted, a ten person team were effectively unable to work. It took their (out-sourced) IT over a week to restore it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
