remcob

The example is called "Privacy Preserving Search". If the server could see which row was accessed, that would not satisfy the privacy requirement. This implies that each query needs to process all the rows equally (and all in the same complicated encrypted way).

Provable privacy like here or in zero-knowledge proofs is generally extremely expensive because every possible execution path needs to be taken each invocation. This is multiplied by the overhead from each simple operation becoming a complex cryptographic one.

It's odd to have the documentation in a .docx file in the repo. The code itself is not very readable. The core of it is something like (simplified):

    function mix(uint64 a, uint64 b) {
        a ^= secret
        b ^= seed
        hi, lo = mul128(a, b)
        seed = hi ^ lo
    }

It's elegantly simple, but depends critically on 'secret' not appearing in the data.

> This is a hash designed for non-cryptographic use

The Readme specifically says "you can modify it to yield 128-bits or more if you want a cryptographically secure hash."

Which is a problematic statement, because it is not designed for cryptography even if you extended the output to 256 bit. It's not the output length that makes it cryptographicaly secure. (Rather it's the difference between "you won't find collisions by accident" and "you won't find collisions even if you try really hard using very sophisticated math", but there are more requirements.)

This is similar to the issues with a different hash by the same Github user posted two weeks ago:

https://news.ycombinator.com/item?id=23103521

Making fast non-cryptographic hash functions is a fun challenge and I appreciate the projects, but please, please do not make any claims about cryptographic properties!

Are there any VST containers? Something that will wrap the VST, intercept under-runs or other bad behaviour and substitute some alternative signal (zero, passthrough, etc.). This could also be part of the host software.

The article and your comments inspired in me the idea of a wave-net based VST learning wrapper. If the real plugin fails, substitute a wave-net based simulation of the plugin.

I'm confused. Supercop is a benchmark for cryptographic hash functions, but SMHasher is a test for non-cryptographic hash functions. The use cases list cryptography, but also universal hash functions which are generally not crypto-grade. It compares itself to the SHA hashes, but only has 64 bit output.

Is Beamsplitter supposed to be cryptography grade or not?

> Before shredders got good.

I would expect shredders these days to be easily defeated with a scanner and some clever algorithms. Is that not the case?

This video does a great job explaining it: https://www.youtube.com/watch?v=Erp8IAUouus

The summary is that the USA does not have an official national person identity number. The SSN is the closest approximation, so it is being (ab)used as one. This is despite that it is explicitly not designed for it and has some qualities which make it less suitable (the numbers are small and very predictable).

In general, nearly every national-identity-system suffers from a contradiction between assigning identities and identifying. Where the number you get assigned is simultaneously your identity and a secret you use to establish your identity. There are initiatives to solve this using cryptography, but this is complicated by political attitudes towards privacy and government tracking. I dare say in the USA this is more pronounced due to both the problem and the political attitude against solutions being more pronounced.

Indeed! And this is not necessarily a downside, sometimes you want to preserve the flags.

Intell added the MULX instruction that is similar to MUL, except that it doesn't touch the flags. It's very useful in bignum math.

In the article, there's a whole path from source to JVM bytecode to ARM assembly. With auxiliary goals like bytecode size. This makes it interesting to include add-double because it has a simple bytecode encoding ('DUP ADD' compared to 'PUSH 2 MUL') and it is interesting to see what the several compilers do with it along the way in terms of optimization.

Interesting info on 8086. Another approach that doesn't apply to OP's article, but does to x86 assembly is (ab)using LEA for small multiplications. At 2 clock cycles it looks competitive with shift for doubling, but can also be used for multiples like 3 and 5.

Adding unsafe can even slowdown your code. The unsafe block prevents the compiler from making certain assumptions, which can prevent some optimizations from happening.

'unsafe' is like telling the compiler 'trust me on this', and the compiler (not fully understanding what is going on in there) wisely decides not mess with what you wrote.

Another fast way to double a number is to add it to itself.

There's a nearly identical issue in LLVM [1]. So neither are currently able to handle ADCX/ADOX in their IR and can only support it through inline assembly.

I was hoping LLVM could maybe bypass this IR limitation for the iXYZ types and generate the optimal instruction sequence, but from your assembly it looks like that doesn't happen either.

[1] https://bugs.llvm.org/show_bug.cgi?id=41546#c1

> or it's own JIT compiler that uses the MULX, ADCX and ADOX instructions.

Does LLVM's bigint implementation use those instructions? Last I tried LLVM can not handle the required data-dependencies on individual carry bits, making it impossible to use ADCX/ADOX in LLVM without inline assembly.

> Does the compiler guarantee constant time? If not, it's still useless for cryptography.

Side-channel resistant algorithms are only required when you are handling sensitive data. This is often not the case when you are verifying signatures, verifying proofs or generating succinct proofs of computation without a zero-knowledge requirement.

Do you have more information on how to do that?

Making things resilient against a kilowatt of non-ionizing microwave radiation seems challenging, in my experience it will burn the traces right off the PCB. A different game from the more common radiation-hardening where the concern is low power ionizing radiation.

Creative idea! There are no branches or closures, but the language does allows loops and recursion. These have non-zero cyclomatic complexity. A loop with either 0 or 1 runs is basically an if statement.

I know it's a joke but: Mugs have a tendency to be put in microwaves, making them a dangerous place for electronics.

If you find yourself receiving a questionable mug, time for a glass of warm milk.

> Physics engine like Bullet or ODE to calculate the simulated trajectories

Probably not, the trajectories are simple parabolic and you can assume perfect elastic collision. Easy enough to implement, compared to interfacing with a physics engine. In fact, it sounded like he approximated the ball by a point and ignored the radius.

> They're like sudoku or crossroads, interesting and somehow intellectually stimulating but they don't help shape/change/modify the world around us.

I don't think this is accurate: sudoku and crossroads have deterministic known solutions. Solving them is a mostly mechanical feat and indeed somewhat useless beyond the joy of solving.

In contrast, the challenge of creating these sorts of programs is creative and open ended. It is very well possible that someone will come up with an even more efficient algorithm. Or a much simpler one. Or just a completely new strategy.

As to the usefulness, these little toy programs are a constant source of inspiration for solving actual real world problems. A perfect example of this is Algorithm X. One of Knuth's toys that solves Sudoku puzzles. The same algorithm is easily adapted to solve scheduling problems and actually is a major innovation.

Would be fun to take all this data and interpolate it to all the 16M colours using a natural language model. We'll need this if we want to stand a chance against at ten bit colour depth.

Yes, but due to lazy-evaluation that won't happen until you do something with the sorted list. Your performance may just blow up in some seemingly unrelated place.

My biggest problem with Haskell is how GC and lazy-evaluation makes it very difficult to reason about what the hardware is actually doing at a given point. I know there ways to inspect and control it, but I've found myself preferring languages that have simpler mental models.

What's wrong with it?

The function in Option linked above by steveklabnik has signature

    fn map_or(self, default: U, f: FnOnce(T) -> U) -> U

a fold has the signature

    fn fold(self, init: U, f: FnMut(U, T) -> U) -> U

The difference is in the closure. in map_or the closure gets called at most once with one argument, in fold it can get called many times with two arguments. This makes `map_or` and `fold` distinct functions. While you could argue that the distinction between FnOnce and FnMut is Rust specific, the difference in number of arguments should also exist in Haskell. And in fact in Haskell the `map_or` function is called `maybe`:

https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-...

(I'd argue the name `map_or` is more descriptive than `maybe`, although it does lift the result out of the Option monad which is unconventional for a map.)

> Another example are the async/await syntax.

Besides the GC that is already mentioned, Haskell has lazy evaluation which gives you coroutines for free. Coroutines are more or less synonymous with async, so in Haskell the implementation is a no-op.

From what I read, much of the challenge of adding async to Rust was in designing the coroutine mechanism, which is a substantial language extension.

To match the semantics of a 'fold' the closure would have to receive two arguments: the default value and the Some value.

(I don't think Option has such a function, and I don't see why it should.)

> encode the difference between what is predicted and the actual data

Minor nitpick: In the idealized model there is no single prediction that you can take the difference with. There is just a probability distribution and you encode the actual data using this distribution.

Taking the difference between the most likely prediction and the actual data is just a very common implementation strategy.

Ah yes, textbook "Embrace, Extend, Extinguish" strategy. Very ironic that GNU now looks like it's following this pattern (obviously unintentionally).

Due to quarantine remote working, a lot of people are obliged to use Zoom. To some Zoom has a reputation of not taking security seriously, so they feel forced to compromise the security of their computers. Personally I think this reputation is justified.

You can access Zoom meetings through a pure web interface without installing anything. The experience is somewhat reduced.

Download and look at all the examples included with Golly: http://golly.sourceforge.net/

Most amazing topics in CA have an example included, including universal constructors.

Modern cryptography libraries make sure that the execution path (and memory access patterns) do not depend on sensitive data. Usually this is what is meant with 'constant-time'.

If a debugger can read out registers or memory you can just read out the sensitive material of course.