remcob

LLVM (Rusts' backend) doesn't support the Xtensa instruction set, which makes this so complicated. The newer ESP32-C{3,6} instead use a RISC-V instruction set which is already supported by Rust, so its much easier to set up.

So far I managed to get basic serial coms working, but am waiting for some HAL so I can build a blinky LED.

It's the 'one-electron universe' theory [0]. In short: there is one electron that keeps going back and forth in time to play the role of every electron we see. A particle 'going backwards in time' is mathematically identical to its anti-particle, which we know exists, so the whole idea isn't too far fetched.

I don't think it is falsifiable, so not really scientific, but a fun theory to believe in.

[0]: https://en.wikipedia.org/wiki/One-electron_universe

What's the current best alternative for boat dwellers?

Lyra is also a speech-only codec, yet is included in the comparison.

Note also that Codec2 had some experimental work extending it with the WaveNet neural network, which improved the performance.

Given both of this, it seems disingenuous to exclude Codec2 from the comparison. I can only assume its left out because it performs well at even lower bitrates.

Could that radiative energy be turned into propulsion, at least theoretically?

I use brackets with a subscript as notation for the modulo operation. This way expressions with multiple / nested moduli become much more readable. I'm particularly fond of how concisely the Chinese Remainder Theorem can be stated:

https://xn--2-umb.com/17/chinese-remainder-theorem

IIRC, I tried this method, but did not see any performance improvement. The method replaces a single `divq` instruction with a table lookup and several multiplications. On modern processors this is no longer a worthwhile trade off.

Here is my optimized in-place Rust implementation [1].

It is a very tricky algorithm to get right. There are many edge cases that only happen for ~2^-64 fractions of the input space, so hard to find even with fuzz-testing. Best strategy is to implement it for small limbs first, and fuzz that well.

[1] https://github.com/0xProject/OpenZKP/blob/master/algebra/u25...

> using a hash of the ID

Hashing the IDs won't solve their lack of entropy. Crude example: If you hash your pincode I still have only 10^4 values to try.

The easiest way to fix this is to add an access token column that is cryptographically random and use both the ID and the token in the URL.

If you trust the 80 bits already in the ID the token only needs to be 80 bits for a total of 160 bits of entropy. But if you do that you have to make sure that a missing ID and invalid token are handled identically from the attackers perspective (same reply, same timing).

> No, I cannot adequately explain why the hyphen moves. Draw your own conclusions.

The hyphen is there because ZK-SNARKs are a subset of SNARKs. Where a general SNARK may leak some or all of the knowledge as part of the proof, a ZK-SNARK can not leak a single bit.

For every lucky person making $500k there are 100 people loosing $5k.

I put the speed of sound purely as a comparison. The local speed of sound is irrelevant because the dust was moving with the medium and not relative to the medium.

Napkin math: That column of dirt went up ~20 km in about 30 seconds. That's almost twice the speed of sound.

Incredible how its size makes it look slow.

This optimization problem is very similar to that of minimizing the diagonal bandwidth of a matrix, a common problem in large numerical computations [1]. It is also related to cluster finding in graphs and graph layouts by considering the adjacency matrix.

The difference is that in both those cases the values are boolean, but in this post the cost function is weighted.

[1] https://en.wikipedia.org/wiki/Cuthill%E2%80%93McKee_algorith...

With a one-off precomputation you can do a lot. If you store the distance to exit in each cell you can introduce a slight bias towards the exit. Easy to implement but not very realistic since it assumes things the guests can not know.

More realistic would be observing that the entry and exit are on the outer edge and the maze is simply connected, so a trivial left-hand rule [1] will solve the maze in linear time. On its own pretty boring. You could ad some randomness to make it interesting. But would it still have linear expected solving time if you do that?

[1]: https://en.wikipedia.org/wiki/Maze_solving_algorithm#Wall_fo...

Those are valid examples, but modules are much older than that: https://en.wikipedia.org/wiki/Modular_programming#History

It really shows Stroustrup's point on how most of these programming concepts have been around for a long time.

This depends on your exact definition of an FHE computation. You could imagine a definition under which you can consider the whole scheme a single Turing complete FHE. But this definition would have to accept that the FHE computation is unbounded and leaks computation length (as would any Turing complete scheme).

I don't like the name "termination oracle", it sound too much like "halting oracle" which is not what is going on here. All we do is add an outer while-loop, a simple algorithmic transformation. I wouldn't even consider that an oracle.

Imagine a FHE circuit that executes a single webassembly instruction. This is a finite circuit that takes as input the program, machine state and external input (all encrypted). As output it returns the (encrypted) new machine state and a single unencrypted bit indicating if the program terminated or not.

Now you can run the FHE step for as many times as the algorithm requires, giving you a FHE-VM that can execute any WebAssembly program from your favorite Turing complete programming language.

The limitations are that you need to define a bounded machine state, which technically breaks the Turing completeness. In practice this is no different from your laptop having a finite amount of memory which disqualifies it as a Turing machine. Real Turing machines don't exist.

The other limitation is that the FHE executor can now see the total run time of the algorithm, which was secret before. This is similar to a timing side channel and similar mitigations apply.

As others have pointed out, if you have a concrete algorithm you can do something much simpler than implement a VM. The Collatz sequence is good toy example of an algorithm with unknown loop bounds. You would make a FHE circuit that iterates a single step using the same overall design.

Would you consider elliptic curve cryptography conceptually difficult? It's certainly more complex than RSA, but over time great educational resources have been developed. The same will happen for these post-quantum schemes.

A conjecture is a proposition that is suspected to be true. So there would be no proof in the paper, but likely some arguments why the authors expect it to be true.

> wish there was a brain cleaning solution

'Drug-induced amnesia' to reduce long term memory generation is a thing and is sometimes used before traumatic surgical procedures. It needs to be taken in advance and is probably not very healthy. Plus I would have serious ethical concerns with jobs that would encourage that.

Indeed, understand-ability is a double-edged sword in cryptography. In general it's best to follow Kerckhoffs's principle and make sure you understand why it works, or risk that your adversary learns more than you do.

> Quantum computers can't break modern symmetric crypto.

Much like we don't have proofs that it is classically secure we also don't have proofs it is secure in a quantum setting. But absence of proof is not proof of absence. In fact we know that Grover's algorithm halves the strength of any hash function. In general you should assume that symmetric cryptography is easier to break on a quantum computer than on a classical one because they are strictly more powerful.

In case of RSA and Elliptic Curves, we known there are theoretical quantum algorithms that undermine the security. But for Lattice cryptography there are actually proofs that they remain secure in a quantum setting.

There's a big difference between symmetric and public key cryptography when it comes to this sort of explainability.

Public key cryptography like RSA, Elliptic Curves and Lattices have elegant mathematical theories behind them. Learning those will teach you much about why things are the way they are and how the security boils down to well known hard problems.

Symmetric key cryptography like SHA2, SHA3 and AES don't have nearly as much theory behind them. It's a bit of a dark art where functions are designed to thwart known attacks. There is no foundation like a proof that shows breaking SHA2 is equivalent to prime factorization or anything like that.

This doesn't necessarily have to be the case, there is research in 'provable secure hash functions', but these tend to perform worse, and we value performance a lot in symmetric crypto.

I tried cache-oblivious algorithms for some numerical code, but found them underwhelming. The cache-oblivious model does not consider the effects of prefetching and cache line associativity. Both can make a huge difference.

They are a great starting point and work well for the RAM/Swap level of the memory hierarchy, but for the L1/L2 caches manual tuning still pays off. This unfortunately makes the implementation non-oblivious and even depended on the specific CPU used.

As a typography and Polish enthusiast, it bugs me that "Zloty" is not spelled "Złoty" with an 'ł'.

It has current practical applications in inter-bank fraud detection, where you want to query if someone is on someone else's blacklist but not reveal the blacklist or the person being queried.

These applications can easily handle an 80 sec delay. It's also likely that queries scale well by batching into larger combined queries (since you need to involve every row already anyway).

In homomorphic systems the server only sees the encrypted result. Since it can not decrypt it, it doesn't gain any information from it. And indeed the encryption is scrambled differently for each query, otherwise you could learn if two values are the same.

You should compare them to what the performance numbers where 5 and 10 years ago. Homomorphic crypto systems have become many orders of magnitude faster quite rapidly. While they are still no where near non-homomorphic solutions (and likely won't ever be), they have only recently become practical for applications where performance doesn't matter and privacy is valuable (in the sense that people pay a premium for it, which is often not the case).

I was oversimplifying to convey an intuition on why this is so hard. But yes, this is an active area of research.

In this academic field the standard for privacy is usually extremely high. Even if you only access half of the rows, that still leaks one bit of information and would not be considered zero-knowledge.

People are working on it. The biggest problem is that cryptography usually requires bignum math and GPUs are not optimized for that. FPGAs are also being researched. The cost/benefit is not as big as you would imagine, CPUs are pretty optimized for bignum math.