![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
thewayneThe Swiss canton of Basel-Stadt had an election. And the election included some evoting, a system being piloted to help people to vote who are living abroad or who are disabled.
Guess what!
THREE USB sticks supplied with decrypt keys failed to work, and 2,048 ballots could not be counted. The ballots are too small a number to affect any results as they represent less than 4% of the votes cast.
Basel-Stadt election officials have delayed announcing election results, and an investigation has been begun.
Gee, if only they'd also written the keys down on CDs or DVDs. Oh, wait! Computers don't have optical media drives anymore. And it's not really best practices to send decrypt keys via email or cloud services.
NEVER EVER EVER treat USB sticks as permanent media! If you copy a file onto one to move it to another computer, copy it off ASAP! They will fail, and at the worst possible moment. I carry a 512 gig USB stick on my key ring, it's very cool with both USB-C and USB-A ends on it: very useful. But if it fails some day - AND I EXPECT IT TO - not a big deal.
Now, let's talk about the number of ballots that can't be decrypted: 2,048. This is a very curious number to report, because it's a very important number in computers: it's a power of two. Computers only know two numbers: zero and one. Everything is based on binary powers of two: 1, 2, 4, 8, etc. 2048 is 2 to the 11th power. It suggests that this may not be a problem with the USB keys, but rather with the encryption software itself. The implication that I got from the Register article was that the USB keys could be read, but the decrypt key didn't work. Keys usually have built-in checksum, which is a mathematical computation that ensures that the info that you're storing hasn't been tampered with. It's just like your credit card numbers: you can instantly verify that it's a valid credit card number (and it's actually a pretty cool formula, you can look it up). You recompute the checksum, preferably comparing it to a second copy, and it tells you if the key has been tampered with. The article didn't go into this detail.
So let's talk about integer overflow! Every piece of information is represented, ultimately, in binary. Am 8-bit binary number - a byte - can hold a maximum value of 255. That's all eight bits turned on: 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128. What happens when you add one to that number? The obvious answer is that it becomes 256, but that can't happen. It's one byte, eight bits. To represent 256, you need nine bits, we only have eight. You now have an overflow situation. Sometimes the byte flips to -255, sometimes the program just flat-out crashes. You can't say with certainty without more information: what language was used, what compiler, etc.
A problem with some computers was that an overflow could cause the program to write into memory that was not supposed to be accessible to it, which could potentially cause a computer crash. The fun stuff was when hackers figured out how to make programs READ memory where they weren't supposed to: this allowed them into areas that the operating system programmers didn't anticipate and allowed the lifting of system passwords and all sorts of fun stuff! But that was in the past, operating systems are somewhat better designed now.
One VERY famous example of integer overflow was the Sid Meier's game Civilization and Nuclear Gandhi. In the game, as in life, Gandhi as a country's leader, was a peaceful guy and not militarily aggressive. In the game's code, there was a hostility counter, which was a small integer, I don't remember how big it was, let's say it was four bits, for a maximum value of 15 (1+2+4+8). 15 was maximum peaceful civilization. -15 was maximum war state, 'gonna nuke your ass' mentality. The programmers forgot to do a bounds check on that variable, and if India was at 15, and something increased it by 1, rather than ignoring the increase since they were already at Nirvana, it overflowed to -15 and they went total rage-monster and started throwing nukes at all their neighbors. Nuclear Gandhi.
Encryption programs are REALLY complicated! With 2048 being a binary power of two, it's quite possible that there is some sort of subtle bug lurking in the encryption code that didn't show in testing that's preventing the decrypt keys from working, and that it's not actually failed USB keys.
But still, my advice holds: do not trust USB keys for permanent - or critical! - storage.
https://www.theregister.com/2026/03/11/swiss_evote_usb_snafu/
https://it.slashdot.org/story/26/03/11/1953224/swiss-e-voting-pilot-cant-count-2048-ballots-after-usb-keys-fail-to-decrypt-them
Guess what!
THREE USB sticks supplied with decrypt keys failed to work, and 2,048 ballots could not be counted. The ballots are too small a number to affect any results as they represent less than 4% of the votes cast.
Basel-Stadt election officials have delayed announcing election results, and an investigation has been begun.
Gee, if only they'd also written the keys down on CDs or DVDs. Oh, wait! Computers don't have optical media drives anymore. And it's not really best practices to send decrypt keys via email or cloud services.
NEVER EVER EVER treat USB sticks as permanent media! If you copy a file onto one to move it to another computer, copy it off ASAP! They will fail, and at the worst possible moment. I carry a 512 gig USB stick on my key ring, it's very cool with both USB-C and USB-A ends on it: very useful. But if it fails some day - AND I EXPECT IT TO - not a big deal.
Now, let's talk about the number of ballots that can't be decrypted: 2,048. This is a very curious number to report, because it's a very important number in computers: it's a power of two. Computers only know two numbers: zero and one. Everything is based on binary powers of two: 1, 2, 4, 8, etc. 2048 is 2 to the 11th power. It suggests that this may not be a problem with the USB keys, but rather with the encryption software itself. The implication that I got from the Register article was that the USB keys could be read, but the decrypt key didn't work. Keys usually have built-in checksum, which is a mathematical computation that ensures that the info that you're storing hasn't been tampered with. It's just like your credit card numbers: you can instantly verify that it's a valid credit card number (and it's actually a pretty cool formula, you can look it up). You recompute the checksum, preferably comparing it to a second copy, and it tells you if the key has been tampered with. The article didn't go into this detail.
So let's talk about integer overflow! Every piece of information is represented, ultimately, in binary. Am 8-bit binary number - a byte - can hold a maximum value of 255. That's all eight bits turned on: 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128. What happens when you add one to that number? The obvious answer is that it becomes 256, but that can't happen. It's one byte, eight bits. To represent 256, you need nine bits, we only have eight. You now have an overflow situation. Sometimes the byte flips to -255, sometimes the program just flat-out crashes. You can't say with certainty without more information: what language was used, what compiler, etc.
A problem with some computers was that an overflow could cause the program to write into memory that was not supposed to be accessible to it, which could potentially cause a computer crash. The fun stuff was when hackers figured out how to make programs READ memory where they weren't supposed to: this allowed them into areas that the operating system programmers didn't anticipate and allowed the lifting of system passwords and all sorts of fun stuff! But that was in the past, operating systems are somewhat better designed now.
One VERY famous example of integer overflow was the Sid Meier's game Civilization and Nuclear Gandhi. In the game, as in life, Gandhi as a country's leader, was a peaceful guy and not militarily aggressive. In the game's code, there was a hostility counter, which was a small integer, I don't remember how big it was, let's say it was four bits, for a maximum value of 15 (1+2+4+8). 15 was maximum peaceful civilization. -15 was maximum war state, 'gonna nuke your ass' mentality. The programmers forgot to do a bounds check on that variable, and if India was at 15, and something increased it by 1, rather than ignoring the increase since they were already at Nirvana, it overflowed to -15 and they went total rage-monster and started throwing nukes at all their neighbors. Nuclear Gandhi.
Encryption programs are REALLY complicated! With 2048 being a binary power of two, it's quite possible that there is some sort of subtle bug lurking in the encryption code that didn't show in testing that's preventing the decrypt keys from working, and that it's not actually failed USB keys.
But still, my advice holds: do not trust USB keys for permanent - or critical! - storage.
https://www.theregister.com/2026/03/11/swiss_evote_usb_snafu/
https://it.slashdot.org/story/26/03/11/1953224/swiss-e-voting-pilot-cant-count-2048-ballots-after-usb-keys-fail-to-decrypt-them
no subject
Date: 2026-03-13 12:28 am (UTC)Hah! Yeah, clearly an overflow issue. How funny! I have Humble Pi, haven't gotten around to reading it. I'll have to move it up my priority list.