JanisErdmanis

This is somewhat unrelated to what I posted, but interesting. At what time does voters get this hash? Is it after the cast their vote in which cases why wouldn’t coerces/bribers ask it as receipt that voters had cast their vote in a certain way?

This attack vector is no different with paper ballots.

> But the few experts that are able to verify the process and have the computer knowledge

It sounds like you are not familiar with the concept of verifiability or more precisely E2E-V for evoting systems that can be attained. The goal is to never trust the software that is running the machines or officials and thoose are kept accountable with a public cryptographic evidence produced along with final tally. They still are trusted with not sabotaging the process and assuming that one or few parties are not corrupt to ensure vote anonimity, but never with integrity.

It is tough to convince oneself that all attack vectors are being considered. The key idea is that a coercer or briber cannot always monitor their subjects, which leaves a window of opportunity for voters to cast their desired vote and set up fake credentials for their devices. This assumption, however, falls apart when the coercer or briber asks for voters’ devices and corresponding PIN codes during the voting period. I am motivated by the belief that such an attack vector is, in most cases, unrealistic.

Regarding your suggested attack vector, where the briber asks for a video of the screen showing how the number is displayed on the screen, this can be resolved with fake credentials. When creating a fake PIN code, the voter can specify inputs and outputs to the device with which the video can be taken. Fake credentials can further create fake credentials, so it is not possible to distinguish them.

One way to achieve verifiability is through deniable tracking numbers computed locally in network-disconnected devices. To ensure that they are deniable, they can only be computed after all tracking numbers along the votes are made publically available, which can be realised by publishing a secret code that the voter inputs into the device. That way, when the coercer/briber asks for a vote to be cast in a certain way, the voter can select another tracking number from a public list and show it to them. Meanwhile, computation on the device ensures that it does not have access to resulting tracking numbers and corresponding votes with which it could deceive the voter. Meanwhile, the cryptographic proofs ensure that every voter has one unique tracking number. This is the general idea of the Selene system.

> why does a voter want to see their ballot?

Because of potential malware on the client's device that can manipulate a vote before it is cast.

One way to resolve the issue is to use a distributed randomness generator like DRand which is threshold decryption based and hence can offer some robustness as well.

The website on VoteXX and associated 4 page preprint does not offer comprehensive overview of the system. What happens to verifiabiloty when the vote is nullified? Does voter sees that the vote is cancelled and hence also coercer/briber?

Warning: This is going to be a rant.

The Belenios voting system is one of the E2E verifiable ones that allows the voter to ensure that their vote is correctly counted without submitting trust to a third party, which is necessary to prevent a corrupt election authority from deceiving and manipulating election results. However, it is also one of the underperforming ones in terms of usability. Like most of the existing E2E verifiable systems, deployability is a logistical nightmare if one wants to safeguard both privacy and resistance against sabotage.

In particular, if I understand correctly, individual verifiability is ensured through a challenge where the voter, after casting a vote to the server, has a chance to test the voting client by challenging it with revelling encryption exponent to the server, which then can decrypt the vote and show it on the screen. This one is a bit concerning in itself, as the voting client can decide to manipulate only votes cast for one candidate. Whereas checking and casting the same vote again would reveal the vote to potentially corrupt authority. Imagine explaining to ordinary voters such verifiability guarantees. There are better systems where one can get a tracking number at the end of the vote and check it with all cast votes when they are decrypted (one can look up Selene).

Another issue with the system and all existing E2E verifiable voting systems is the deployment of a threshold decryption ceremony. To recap for everyone. Before the elections, the authority manages the creation of a shared public key between multiple parties, which voters use to encrypt their votes during the vote. After the vote, all encrypted votes go through reencryption mixes or are homomorphically tallied and then finally, the votes are threshold decrypted. The challenge here is choosing the redundancy threshold of a number of all parties that need to come together to decrypt the election result. If too few come together, the election result can remain undecrypted, whereas if the hold is set too low, a small minority could collude and see how everyone has voted. Hence, securing both privacy and robustness is an expensive activity.

The website offers the service for those who don’t want to deploy the system themselves. The issue is that the voters’ privacy is handed over to the running service. There is no way to verify to what extent the parties used by the organisation are truly independent and would safeguard their vote privacy.

My biggest gripe is that theese arguments don’t land well to thoose who are acustomed to mathematical formalism of security definitions and proofs. The E2E verifiability with strong privacy guarantees can also be achieved in expoinentiation mix setting wihtout the need to threshold decryption ceremony [1, 2]. Receipt freeness is still an unresolved challenge here, but I see a path to resolve it with ideas similar to those used in Selene. Whereas if you are concerned about fairness not being distributed between multiple parties, please explain to me an attack vector there that can’t be accounted for!

[1]: https://www.usenix.org/legacy/events/evtwote11/tech/final_fi...

[2]: https://eprint.iacr.org/2024/1040

> RAND estimated 890 MWh per key to be broken

Can you give a reference? Also, how is heat generated within the quantum processor as operations are unitary?

I have forgotten the source where I stumbled on the requirement for a qubit error rate to run the Shor algorithm. I would greatly value it if someone could put a key reference here.

A recent result considers a generic error model and a subclass for particular kinds of prime numbers [1]. The important result is $epsilon > cn^{−1/3}$ where epsilon represents qubit error rate and n number of bits in the factorised number. As $n = 2^N$ where N is a number of qubits, the result:

error_rate < const/2^{N/3}

Therefore, the error rate must decrease exponentially with the number of logical qubits with which the computation is made.

[1]: https://arxiv.org/pdf/2306.10072

> But we did not invent transistors from quantum physics -- we created transistors long before we had an explanation of how they worked, and we have continued to improve and iterate by making advances in material sciences and experimentation, not by applying first principles. Things like blue LEDs were invented by tinkering rather than by solving Lagrangians.

In a similar spirit ships were built, steam engines made and applications of superconductivity imagined long before the objects were understood from first principles. Creation often proceeded theory nevertheless it is still useful for optimizing designs at later stages.

Quantum error correction produces logical qubits that have smaller nonzero error rate. Thus it needs to be applied repeatedly to achieve a necessary error rate to produce meaningful results. For Shor algorithm the error rate needs to decrease exponentially with the number of qubits. Thus even though IBM has a hundred qubits QCs they still only have managed to use five qubits to factorize a number 21.

> The strict way to handle indexing, I suppose, would be to have distinct 1-indexed (e.g. Ind1) and 0-indexed (e.g. Ind0) Int-based types, and refuse to accept regular Ints as indexes.

I would be happy if unsigned integer UInt would start indexing from 0, whereas for signed integer it would start from 1. Also a module level parameter where preference on whether a literal integer shall be interpreted as Int or UInt would alleviate many usability issues there.

> Plenty of jobs require you to hand your social media passwords to your employer.

Can you elaborate with examples or references?

In practice, that's what would happen. Move around until seeing some larger gravitational pull, likely indicating some deposit. However, formally, this is not correct due to the mere fact that the gravitational force is proportional to 1/R^2, just like a Columb force. Thus, there are infinite numbers of mass distributions that produce the exact same gravitational field on the surface. The planet could be hollow, and we would not know it only from the field measurements.

A practical constraint is mass density, which has maximum and minimum values. We can make a crude approximation that the planet's density is constant, evaluate the field on the surface from the planet's shape and compare it with measurement. This would be more useful, but still, it wouldn't tell us whether there is a combo of water reservoir and a large massive deposit below it.

The problem is that the planet could be hollow and produce the same gravitational measurements on the surface and outside. It needs to be coupled with a model that introduces constraints for the inverse problem to be defined.

We currently don’t know how to calculate the nucleus’s bound state despite a thorough understanding of individual pieces that make it together, as explored in colliders like CERN and others. The problem is similar to telling at what temperature water is boiling, freezing, and its density from knowing the properties of a single water molecule. We understand quantum mechanics and Columb forces govern the properties; it is incredibly hard to renormalise the system from an energy scale of a gas to a liquid or solid. Similarly, it is for a quark-gluon plasma; thus, phenomenological models are used, like how the nuclear potential could look and the masses for different combinations of nuclei.

Has anyone tried to make null as a function? In Julia, there is a `get(null::Function, collection, key)` method which can be used in a syntax:

value = get(collection, key) do

    error(“$key in the collection not found”)

end

This syntax has captivated my attention lately as it seems like a viable alternative to doing an explicit null check before using the value.

The overhead for Go in benchmarks is insane in contrast to other languages - https://github.com/dyu/ffi-overhead Are there reasons why Go does not copy what Julia does?

When I last checked and started the Syncthing setup wizard, I got the impression that to set up the synchronisation between devices A and B; I would have to paste the public key of B in A and the public key of A in B, which is more complex than initialising this step with a token key as Resilio sync does it.

Furthermore, it prevents its use as a public bulletin board where the server can share a read key and allow anyone to keep a copy of the data. I am developing an E2E evoting app where that would have been useful.

I have looked into Syncthing and I found that their E2E setup is too daunting. In contrast in Resilio Sync one can share read/write key and be settled with it easally. If security is of concern one simply puts an expiration time on the key.

Which quantization level are you using?

This seems to be an orthogonal issue. Rust could build the same dynamic library with cargo which could then be distributed. The diference is that there would be a single way to build things.

It is generally harder to introduce vulnerabilities in readable language even more when it is memory safe. Sure life is not perfect and bad actors would have found a ways to inject vulnerabilities also in Rust, Go codebase. The benefit of modern languages is that there is one way to build things and the source code is the only thing that needs to be auditted.

The lesson here seems to not depend on tools written in languages that have complex, obscure build systems and no one is either able or interested to read. Using tools rewritten in Rust, Go or any other languege which resolves dependencies within project seems the only way to do hardening here.

I wholeheartedly agree that the rigidity of most current development environments prevents us from understanding the problem. I would even say it shapes the problems we try to explore the same way a spoken language does.

Many points were the reasons why I am now using Julia to develop a large-scope full-stack application. Revise (package) allows to evolve the program interactively while preserving the system state. For instance, I can have an instance of a struct in the REPL; I change one of the modules, and the available behaviour of the instance can be immediately tried out without recreating the state. Or, when interactively developing a webserver, I find an error on one of the served pages. I changed the piece of code in the module, and it is immediately reflected when reloaded while keeping the existing state.

System introspection is easy as everything is available from the REPL. Default printing is available for all user-defined types, which can be specialised on a wish. Thus, printing an object or even getting to the precise point in the module call stack with an Infiltrator is always accessible.

One pain point regarding file-based organisation is that, in most languages, every file is within its namespace. In Julia, these things are orthogonal. You can have a single namespace organised over multiple files or multiple namespaces within a single file. This generally makes it easier to navigate a large namespace while not being bothered with making explicit imports, etc., when one is still in the exploratory phase.

I can’t really relate to tree-based exploration. Very few times do I find that the direction I have found is wrong, so I do a git reset to a previous commit. Also, there are a few sunk costs migrating from one approach to another when most of the functions are written to be pure.

Another essential piece for explorative development is types. Although some planning is required, it is generally worth it. In Julia, those are checked at runtime, which nevertheless significantly helps to locate issues quickly when doing test-driven development.

It is! Taking into account that only the Schor algorithm is proven to be exponentially faster in factorising numbers and looking into current progress on using it, the threat for RSA 2048 will become real in ridiculous 2^2048 years. This can be estimated by taking three events in factorisation:

2002: factorisation of 15 [1]

2012: factorisation of 21 [2]

2022: factorisation of 35 by IBM (although the article is about number 21, but let’s give them credit) [3]

In a plot, the tendency is somewhat linear, with the factorised number increasing by one every year.

A sceptic immediately replies to this thread, saying we already have 100-1000 qubit quantum computers and are on the path to getting a million qubits in the foreseeable future. That may as well be true. The issue is that the Schoor algorithm requires that the error rate of the qubit operations scale exponentially with the number of qubits. This is why IBM only uses five qubits in [3], although they already had a hundred qubit QCs at that time. It just produces meaningless results when used with more qubits.

This is also why the line for factorisation is about to be linear. If the error rate of the qubit operations decreases by 20% every year and we have exponential progress, the usefulness of the Schor algorithm taken on a log scale would be linear.

The error correction is not a panacea either. It does not reduce errors to zero for logical qubits but rather reduces them after the error threshold is reached. It would require repeated application to get the necessary error threshold to run the Schor algorithm for a desired number, which would require an unreasonable number of qubits.

[1]: https://www.nature.com/articles/414883a

[2]: https://www.nature.com/articles/nphoton.2012.259

[3]: https://arxiv.org/pdf/2103.13855v1.pdf

The only issue though is that Qt does not agree that mobile apps on app stores can use LGPL license due to anti-tivotization clause. Nevertheless they do have a somewhat reasonable pricing for small business of 500$ per year.

Feynman did not bulshit the answer as the interviewer does not have a capacity to understand the phenomena any deeper and he gives all valid reasons why. If instead he would have jumped to writing down a Hamiltonian and constructing a partition function from which magnetization could be derived for a magnet it would have killed the interviewer in obscurity.