libatsha204 uses DNS request to select "0"
Some code within libatsha204 makes a dns request for TXT
of atsha-key.turris.cz
, apparently to get back the string 0
.
It's not clear why this is necessary, it's not overridable (at least in some places like the python bindings, i haven't looked further) and it makes the chip impossible to use without having internet connectivity. When the DNS lookup fails, the chip's hmac operation itself will fail.
This is an odd design decision, and is not well-documented in the README or in the API.
If a machine needs an hmac operation in order to complete its connection to the Internet, this puts the chip's user in a catch-22 position -- no cryptochip without Internet, no Internet without cryptochip.
When it is sucessful (when the user does have internet access), the DNS lookup also leaks the fact of the use of the chip to the network operator.
and it makes libatsha204 much bulkier since it needs to link to libunbound
to do anything.
Shouldn't the library accept the slot number from the user, and delegate policy decisions about reaching into the DNS to some other layer?