Something this API gets right is having a unified interface for both IPv4 and IPv6. With the sockets API, you have to decide for one of them. Changing isn't easy as the constants and structures are all named differently.
While it's possible to use IPv6 sockets for IPv4 connections, this doesn't cover all use-cases. For example, you can't do IPv4 broadcast with an IPv6 socket. Additionally, as most examples are written for the classic IPv4 API, that's what everyone uses per default. Later on, when people complain about missing IPv6 support, they are turned down because it's a ton of work to change.
For majority of applications, supporting IPv6 boils down to using getaddrinfo()/getnameinfo() instead of gethostbyname()/gethostbyaddr(), which results in code that supports both IPv4 and IPv6 and is simpler than the IPv4-only original.
Changing isn't easy as the constants and structures are all named differently.
They are all named "struct sockaddr_storage", no?
You won't even need that most of the time, as it's all dealt with by getaddrinfo and friends (see sibling comment). Sure, there are some cases where it breaks down but the vast majority of software doesn't go there.
The optimal block size is probably the the amount of data which can be transferred with one DMA operation.
For NVMe disks on Linux, you can find out this size with the nvme-cli [0] tool. Use "nvme id-ctrl" to find the Maximum Data Transfer Size (MDTS) in disk (LBA) blocks and "nvme id-ns" to find the LBA Data Size (LBADS). The value is then 2^MDTS * 2^LBADS byte.
For example, the Intel SSD 450 can transfer 32 blocks of 4096 byte per NVMe command, so you'd want a block size of 128 kiB.
You have to trust some hardware, but not necessarily the full stack you listed above.
For example, chipTAN is commonly used in Germany to verify online banking. You have to trust the chip on the banking card and the card reader, but not your computer, network connection, or your smartphone.
A similar device may also work for online voting. The hardware would be simple enough to audit it. Your computer would never learn the vote.
If the chip has its own display and input, and every step of the manufacturing process is carried out under strict supervision by all parties, and every time there's a firmware update the entire software stack is re-audited, then maybe. You raise a good point.
There's the whole business of securely distributing the chips (so they're not swapped out with counterfeits in transit), dealing with theft (and coersion to not report the theft), etc. But yes, if you can get a never-network-connected, brutally simply, completely automated voting device into 230 million hands, then I can't think off the top of my head how to exploit that. I would move on to trying to exploit the tallying system.
At that point, though, is it really cheaper than paper ballots? Perhaps it's worth it to engage more voters, but it still seems like a terrible risk to take - I'm only very grudgingly aware of computer security matters, just because I can't think of a way to exploit it, doesn't mean that one of the 7 billion people out there won't. And it only takes one.
Also I should point out that my original point stands - what you bring up is a million miles from what they proposed in TFA.
This is exactly what the "block third-party cookies" option does. It really should be enabled per default, possibly with a permission prompt for cases where they are useful.
The interesting thing here is that third-party cookies usually allow a central site (e.g. an ad server) to track a user across many other sites. It's almost the other way around here: "other sites" can track status on a "central site".
Not really liberal - leaving out those tags is perfectly fine according to the specification and all compliant browsers will create the same DOM from it.
Is it really? Apart from the missing port-forwarding, DS-Lite seems to be one of the better solutions to the IPv4 shortage to me. There's only a single NAT at the ISP, the local router tunnels IPv4 packages directly to the AFTR. For peer-to-peer applications, both UDP and TCP hole punching work fine.
Maybe some ISPs will implement the Port Control Protocol [1] at some point, which would allow port forwarding with the DS-Lite NATs.
> For peer-to-peer applications, both UDP and TCP hole punching work fine.
Sadly, that's only half correct. Yes, nat traversal usually works to establish connections. But in practice port mappings are not necessarily the same thing as NAT table entries. If your p2p application contacts a lot of endpoints, even from the same source port, this can eventually lead to saturation. At that point you'll get packet drops and ICMP errors.
In other words, on some aftr implementations p2p can lead to resource exhaustion, leading to a pretty bad ipv4 experience.
> Maybe some ISPs will implement the Port Control Protocol [1] at some point, which would allow port forwarding with the DS-Lite NATs.
Some already do. The CPE can forward local mappings to the AFTR.
>This is the definition of a Hash Function. Not a cryptographic Hash Function.
No, a hash function is just any function which can be used to put values into a hash map. If your inputs are numbers, modulo will work fine as a hash function, but is obviously not one-way.
>Cryptographic Hashes should NEVER collide, on any inputs, ever, period.
This is obviously not possible, as the output of the cryptographic hash function is of fixed-length while the input is variable-length. Finding collision just needs to be hard, not impossible.
How is modulo invertible in the general case? If it is, can you demonstrate? I have picked certain numbers and their values modulo 10 are 6, 7, and 8. What numbers did I pick?
It doesn't have to be. Onewayness says nothing about finding "the original x". If a function is one-way, it means that given y (a random n-bit string in the output space of h), it is hard to find any x such that h(x) = y. If your h() is just a modulo operation, this is trivial: just choose x = y.
Ah, I see, way as in path, not way as in direction (which is I think the misinterpretation that leads people to the root of the misunderstanding). So, there's one path to get from x -> y, but it does not imply you can't get back to the original x. In that respect, "way" is an unfortunate word to use, at least as it's used in modern English.
You can demonstrate that a number input into modulo belongs to a specific group. Even not knowing the specific value of modulus you can drive it by observing statistical properties of the output. (which is why modulo hashing gives many collisions)
modulo will work fine as a hash function, but is obviously not one-way.
Modulo is a one way trap door operation.
Proof via arrogance:
X % 100 = 50
Solve for X
Solution X = F(n) where F(n) = 100*n+50 (for all n > 1)
This does indeed meet the requirements of a hash functions. Modulu is a bad hash function because it is poorly distributed.
Cryptographic Hashes should NEVER collide, on any inputs, ever, period.
>This is obviously not possible
NIPS says if you observe 2 inputs of a cryptographic hash which compute to the same digest the hash is considered depreciated. So yes my definition is correct.
Obviously yes all cryptographic hashes aren't unique for every input. As they maybe N bytes long. And simply a logic will tell you there is more information in N bytes of data vs 64 bytes (512bits).
The real issue is, prove it. Testing even the 512bit address space will take you longer then the heat death of the universe, so good luck!
No - per the definition of a trapdoor function:
"For any k ∈ K, without trapdoor tk, for any PPT algorithm, the probability to correctly invert fk (i.e., given fk(x), find a pre-image x' such that fk(x' ) = fk(x)) is negligible"
Note that the definition is about a pre-image, not necessarily the input used to create it in the first place.
Second, that definition is absolutely not correct. "Never" would require that the size of the output of the hash function be equivalent to the size of the universe of possible inputs, which it obviously isn't. There's a very important difference between "never be observed in practice" and "never, period." You're not using the language precisely, and that's very dangerous when talking about hashing and cryptography.
Pre-image is even simpler. A good cryptographic hash also prevents second pre-image attack e.g. pre-image based on multiple hashes.
None of those properties is needed for indexing into hash table. Good collision resistance is all that is required and salting for more paranoid cases.
Looking at the source code, it's actually licensed under the GPLv3 as well, so the software seems to be free, just the resources and game content aren't.
While it's possible to use IPv6 sockets for IPv4 connections, this doesn't cover all use-cases. For example, you can't do IPv4 broadcast with an IPv6 socket. Additionally, as most examples are written for the classic IPv4 API, that's what everyone uses per default. Later on, when people complain about missing IPv6 support, they are turned down because it's a ton of work to change.