@MaartenBodewes What's the main reason crypto isn't or can't be fast? The reasons I can think of are all due to the inability to use certain processor instructions. No vectorization. No AES-NI. Sometimes there's no way to access the high bits after multiplying two 64 bit numbers.

You don't get that out of standard C or C++ either though. You need to use unstandardized compiler extensions or inline assembly.

... Would there be any issues (that aren't currently already a thing when trying to write portable C code) if some future C standard said "From now on a plain int is always 32 bits, a long is always 64 bits, and a short is always 16 bits and all signed/unsigned integer types are required to be two's complement."?

It amazes me that 50 years later that there isn't consensus that The Standard Is That There is No Standard is just an obvious and archaic mistake. It's instead argued as a good thing "because optimization".

x86 is the outlier. it's pretty much always sucked as an ISA. Most everyone else fell heavily into standardization, but that was likely due to UNIX. I loathe x86. I only use it on my laptop because it's a Mac because the language support is just so good compared to everything else.

back in the SPARCv7 days, there was an interface for coprocessor calls. Sometimes it was used for Java coprocessors. On x86, I can through and invalid instruction and then use that in fabric to a coprocessor. You could use those tricks to make cryptography fast.

I once took a Xilinx Virtex and attached some new instructions to the PowerPC core. not coming from the x86 world, a lot of what seems to suck is because of 30 years of compatibility. I need to applaud microsoft and intel for that as it's pretty amazing, but OMG, what a shitshow

Actually I'm usually more on the anarchist side of whether computers should make heavy use of standards. Bad decisions can harm us for far longer than they should if everyone keeps using bad practices because a standard demands it. x86 is really scary though.

Programming languages I don't want to be ill-defined. And that's what I'm looking for in a standard. I don't think people notice the metaphor behind programming languages. They're meant for communication. Developer to machine. Developer to developer. Unlike natural languages, ambiguity in these kinds of languages are always a bad thing.

one of the nice things about being on the hardware side is that you are tasked to solve problems and generally, it's because the current approaches didn't work (read in, standard ICs). I've made some really terrible things that worked well for their single task.

@FutureSecurity I see what you were getting at there.

But people have disagreed on that idea historically I suppose. C was called "The portable assembler language". Even though generic code snippets might do different things from one version of the PDP to the next because basic arithmetic isn't handled the same way.

I guess they were thinking "portable" more in the sense that you didn't need to retrain your developers to use a new language before they could read or write code for a platform they hadn't previously used.

@FutureSecurity who does "portable" mean that for? as an example: en.wikipedia.org/wiki/Portable_Executable I can pretty much assure you that no one in CS knows that actual definition of portable. :P

recently, a chunk of calculation code I wrote for BSD failed to execute correctly on Linux. it was POSIX and ANSI strict so it was sort of a shocker. :/

I'm thinking of CS as in the formal study of computing. Not all software developers are computer scientists, so there is variability in different the sub-cultures of programming.

So we mean that code is portable if it doesn't depend on platform specific quirks. More like the old Java slogan of "write once, run everywhere". But maybe it's more accurately "capable of running anywhere".

Grr. That's not what I meant. Hmm...

So in CS it means that your code will be interpreted the same way regardless of who is doing the interpreting. That's why it's import to computer scientists that a language has no ambiguity in its specification. The spec tells you how to read source code and there should only be one correct way to read it.

For other kinds of software people "portable" might mean "works on both Mac and Windows". Same word. Different dialects.

I've not had much luck working with, or hiring computer scientists. Most of it is due to culture I suppose. Then again, when all you do is C, you are setting yourself up for a mess I suppose.

btw, this was not my finest hour: stackoverflow.com/questions/35230027/…

I once ported a bunch of stuff from UltraSPARC to x86... and then realized it was going to be terrible and ported it all to POWER. it still runs on POWER.

And to CS people something would technically still be portable if the software necessary to interpret it (currently) only existed on one platform. But if code is portable it means that when a compiler comes out for a second platform, then no changes would be required to make your code work on that other platform. (As long as both platforms have similar capabilities. There is no working around something like limited RAM or missing communication ports.)

Oh. But if you're a C programmer then you'll never be out of a job. ;) They can't fire you if you're the only one who knows how your code works. And if your code is going to break every time a new processor, OS, or compiler version comes out then there always be demand for that kind of work.

well, I generally am making the hardware so C is about the only thing that I can use. I wish it wasn't job security. :/ I'd rather not be coding. I'm currently using a MIPS that I've memory mapped IO into to run some highspeed ADCs.

Here's the joke I was referencing by the way (I think. It's been a long time since I read it.)

> Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient.

Never mind. It was a joke about C++. Really dated. I thought it was about C.

> C++ is dying off now, but programmers still get high salaries - especially those poor devils who have to maintain all this crap. You do realise, it's impossible to maintain a large C++ software module if you didn't actually write it?

Lol. Really dated. C is so so so much worse in that regard too. It's one of the biggest "write once, run away" programming languages that's still really popular. Javascript is really bad, too, though. PHP was too. But those other two have at least evolved.

I wonder if C is ever even going to get a really minor change like adding namespaces.

Coding is needlessly unpleasant. It also really scares me because our health, money, and freedom is tied up in a broken computing infrastructure.

That was part of the motivation for my username. I was feeling optimistic at the time. We've got a lot of legacy junk holding us back. It's going to take a lot of work and cost a lot of money to replace the old broken systems, but it would be really promising for humanity not to be held back by software ineffeciencies and dangerous bugs.

I knew that replacing old infrastructure was something people will hesitate to invest in, so my hopes aren't too high for the near term future. On the other hand putting programmers out of work is another ethical concern I have. On the other other hand I also consider the ethical implications of software putting non-programmers out of work.

Economic revolution would probably be more helpful to humanity then technological revolution... Too bad achieving that is even less fun, harder, and pays worse.

@FutureSecurity @FutureSecurity Yeah, no the Java low level instructions are just not as fast, and the bytecode overhead is huge for such low level instructions. Yes, AES-NI is not available to the Java PL, but that's not a problem, as it is certainly used by Java intrinsics, where bytecode (of a specific method) is replaced by specialized pieces of native code by the VM.

But e.g. int x = something; x >> 1 uses a 32 bit big endian with sign extension. That's not an instruction you'll find on any modern processor.

I think so anyway, i86 as mentioned earlier, is a mess.

I meant x86. Funny typo, that was my brain inserting a different character.

@FutureSecurity So I meant that mainly bytecode is not that fast. AES and SHA-1/256 extensions can be used so that functionality is relatively fast (- some constant overhead for calls of course)

And compared to Python and most other interpreted languages Java is always fast, although Python and many other languages depend much more on native libraries.

Quantum cryptopocalypse on sale for $600! "With quantum computing emulators accessible to the lay-person, the security of current AES-256 is nearly in the rearview mirror". Ah ah!!

More nonsense.

capable of executing within a quantum emulator

Oh, wow, I'll contact Microsoft, see what they think of that advertisement.

Mickeysoft silver partner. Oh wow.

How do you contact?

Oh, I got a few contacts from when I wrote SkeinFromSpec.

Let's see how useful they are.

@SEJPM no volatile keyword, but volatile reads and writes in ptr module as well as Volatile type i believe that wraps any given T or maybe *mut T

I forget, maybe it's crate?

i've done a bit of hobby osdev and rust gives youall the tools you need though

@Maeher yea thats the point

i want any given multiset to give one hash

so its ok if H(x, y) = H(y, x) - that's the point :P it'd be an issue if there existed a trivial method to find z so that H(S, z) = H(S, x) though

where x=/=z

@Restioson it's a crate docs.rs/volatile/0.2.6/volatile

@Restioson it should be fairly easy to prove that for every fixed S finding (x,z), x=/=z s.t. H(S,x)=H(S,z) is hard

(though I'm not sure this is all the security you need here)

spectrum.ieee.org/tech-talk/telecom/security/…

New Cryptography Method Promising Perfect Secrecy Is Met With Skepticism