zgs

Linear algebra was one of my favourite series of subjects during my mathematics degrees. It has always been fun.

There was only one rocky moment I can recollect, in first year after a three lecture proof which the lecturer finished with words along the lines of: "I won't go through this again because you wouldn't understand it the second time either." Quite possibly true, although I understood the steps of the proof the theorem itself wasn't at all obvious. In later years it became so.

I did expect a title along the lines of: "Hitler predicted global warming decades earlier than the rest of the world".

Meccano tried licensed IP: Gears of War, Rabbids, Tin Tin, Sonic. Possibly others I don't remember.

Lego has more cash and clout to get more desirable IPs with less strict restrictions of course.

I think the real reason for the decline of Meccano/Erector is that it is more fiddly than Lego is. I almost wrote difficult but I don't think that's quite the right word -- there is a lot more freedom in construction with makes assembly, even following instructions, trickier.

I'm not all that surprised. Processors add useful new instructions which can easily improve performance. OpenSSL's assembly hasn't changed for years: MD5 isn't really considered secure and hasn't been for years. Why update it?

Naturally. If it isn't profitable enough, charge more. Basic economics. Any prior promises can be complete ignored and invalidated.

It's still a permutation: shuffling a deck of cards again doesn't make it any more random (apologies to Diaconis). A symmetric cipher is just a shuffle -- no more, no less. Sure, it "feels" unlikely that there would be a problem but can you prove that or prove at least some level of confidence in it?

The bottom line is just AES is good enough. Your data almost certainly isn't worth the effort involved for an attacker even if there was a substantial breakthrough against AES. If it was worth enough, there are far cheaper and easier ways to get access than breaking the crypto: https://xkcd.com/538/

Modern symmetric crypto is secure enough: any problems you hear about are not in the algorithms. Cracking crypto as seen in movies is a complete fiction, it doesn't work like that.

I suggest reading some introductory texts on cryptography to fill knowledge gaps.

You *are* inventing a new crypto algorithm.

A symmetric cipher is a permutation, multiple symmetric ciphers in sequence is still a permutation. There has been no analysis done on the latter to determine if the sequence you use hides a weakness. I'd much prefer a well analysed system to an unanalysed one.

Another example of "roll your own crypto". Just don't.

Honestly, just stick to one algorithm and use that. Choose something modern. There is no evidence that AES-256 has problems. CBC mode allows some alteration of the plaintext but it's limited and noticeable, best to include an integrity check (HMAC or CMAC).

You really don't want to encrypt bulk data using RSA, it's simply not designed for that.

Well behind the times. Look at Eric's http://www.brouhaha.com/~eric/hpcalc/ which emulators the original ROMs.

Any simulator almost certainly lacks the numeric accuracy of the original.

I'm the primary numerical programmer behind the WP 34S (https://sourceforge.net/projects/wp34s/) -- essentially a superset of the 15C plus so much more. This stuff is not easy.

Add three to six more zeros and these breaches will be taken seriously.

Absolutely.

A large asteroid impact will exterminate us. Being prewired and prepared to avoid that is one racial survival requirement.

If this works, this is a game changer.

Prior to this, such accuracy (albeit a fair bit better to be honest) required a base station and RTK (real time kinematics). Dropping that requirement and getting accuracy within 10cm is amazing.

Elon: fucking society one fanboy at a time.

RFC 1149 is worthwhile. It's followup, RFC 2549, rather less so.

I've read lots of RFCs over the years and had too implement (too) many.

Because you don't understand what it is meant to do.

He's a media whore. Little more and little less. That he's insanely rich is mostly luck and timing, rather than competence.

Seriously, are the Russians any worse than the US here?

I doubt they've got anything like the same level of access to the low level infrastructure (at least outside their borders) and they won't have anything like the budget to sweep up absolutely everything.

Bring back Call-by-Name. The one true paradigm.

Ha ha ha ha ha.

This is down to the courts now. Everything else is irrelevant.

Python and R are the two go to modern programming languages for number crunching. Fortran still has a lot of sway. C has a little.

Rust is totally irrelevent in this context.

Lift controllers date from the 1920's. I'd consider them embedded systems.

When you are designing for runs of 50k - 1000k units, this is expensive.

No. At least not with modern caching (or very old page boundary crossings).

A constant time implementation has to avoid tables & compute the values directly (and slowly) or take special care to ensure that all of the table is hit/cached on each access.

Most cryptographic operations are easy to implement. The best part is when you make a mistake, you'll most likely get random nonsense out the end. Floating point code is much more difficult, often you'll get an answer that's almost correct or worse one that's correct most places...

Compilers that did this would break a lot of the constant time code.

Most problems I've seen have been in the way OpenSSL is used not in OpenSSL itself. Sure OpenSSL has issues but naïve use of cryptography in the wrong way is *far* more prevalent.

Not at all.

To be vulnerable, you need to build on a non-vulnerable machine which passes the built in tests, then you need to deploy to a vulnerable one and finally you have to not verify that the deployment works.

Absolutely not what you are implying.

If you build on the machine you will deploy to, the tests won't pass. Problem solved.

If you build on an earlier machine where the tests pass and deploy to a later one and then don't check that the deployment works, you are at risk.

I think proper testing covers both options.

This would add noise to the measurements which should cause an exploit to take longer but it wouldn't prevent the exploit.

Seriously, good.