andi- has quit [Remote host closed the connection]
andi- has joined #nixos-chat
emily has quit [Remote host closed the connection]
emily has joined #nixos-chat
endformationage has quit [Ping timeout: 240 seconds]
drakonis has quit [Ping timeout: 248 seconds]
aria has quit []
aria has joined #nixos-chat
__monty__ has joined #nixos-chat
kraem has joined #nixos-chat
<eyJhb>
I think I will beging to regret having run another half marathon in a couple of hours
<eyJhb>
Already halfway there
<eyJhb>
Can anyone think of a good and simple system, for having a key which is used to validate other keys? It needs to be XOR simple pretty much, as it should be implemented on a embeded system. Currently I just have a 6 int key, which I use to XOR the input with and then shift between addition and substraction between each XOR, and if the final value is 0, then it is OK
<eyJhb>
Which yields something like this (7 instead of 6) - Valid codes in 7 keyspaces is 1000005/30686, so 84 years before I need to replace the keybox as key reuse should not be allowed
<__monty__>
That sounds like a whole lot of nothing tbh.
<eyJhb>
__monty__: it is :p But it is simple and somewhat works
<__monty__>
Does it?
<eyJhb>
Why wouldn't it __monty__ ?
<eyJhb>
Change the key, and the codes no longer works etc.
<__monty__>
I don't understand what your goal even is?
<__monty__>
XORing digits and then alternating sum and difference sounds like AND would be more straightforward.
<eyJhb>
__monty__: basically creating a small embeded device, which can function as a keybox. So I can give a code out to someone e.g. 1234567, they enter it into the box and it opens which reveals a key to my apartment
<eyJhb>
But it would be nice to have them time based as well
<__monty__>
If you're gonna allow about half the keyspace as valid keys what's to keep random people out?
<eyJhb>
It is 3% of the valid keyspace
<eyJhb>
>>> (100/1000005)*30686
<eyJhb>
3.068584657076715
<adisbladis>
eyJhb: Don't you just want TOTP?
<eyJhb>
adisbladis: basically, just not sure how "easy" it is to implement on a microcontroller
<__monty__>
TOTP sounds terrible though. That's only good when the key is generated by a device.
<eyJhb>
__monty__: depends on the lifespan of the token I guess
<eyJhb>
But yeah
joepie91 has quit [Ping timeout: 272 seconds]
drakonis has joined #nixos-chat
drakonis has quit [Client Quit]
infinisil has quit [Quit: Configuring ZNC, sorry for the joins/quits!]
infinisil has joined #nixos-chat
<clever>
,tofu
<{^_^}>
To get a sha256 hash of a new source, you can use the Trust On First Use model: use probably-wrong hash (for example: 0000000000000000000000000000000000000000000000000000) then replace it with the correct hash Nix expected. See: tofu-vim
NinjaTrappeur has quit [Quit: WeeChat 2.7]
NinjaTrappeur has joined #nixos-chat
<__monty__>
clever: Don't like stdenv.lib.fakeSha256? Or the 0's the number of cards in a deck mnemonic.
<clever>
__monty__: longer to type out :P
<clever>
forgot about 52
<__monty__>
It's longer to type but asking an irc bot and copy pasting is surely more work?
<clever>
lol
<qyliss>
It just occurred to me that I could do C-u C-u C-u a in Emacs and get a valid probably-wrong hexadecimal sha256
<qyliss>
that's way quicker than using fakeSha256, which I've been doing up til now
<clever>
i usually just clone a nearby hash and 0 a few digits
<__monty__>
qyliss: A hex sha256 isn't the correct length though.
<clever>
but this fine didnt have one
<clever>
__monty__: nix accepts hashes in both base16 and base32
<__monty__>
Ah
<clever>
but base16 can be confusing, because it converts it to base32 when displaying the wrong-hash error
<clever>
so you cant find the hash it complains about, anywhere
<clever>
ive also found a post from 2013, saying the rpi has a 4th i2c module, that is even less documented
<clever>
and somehow used for the camera
<__monty__>
>.<
<eyJhb>
gchristensen: living lifeform?
<eyJhb>
clever: sounds like a fun hunt you have going ;)
<eyJhb>
Debating whether or not I should 1. Continue on cleaning up 2. Program for my exam project that I need to handover 3. Do the 11 reminders/todos that I have neglected to do for some time
<eyJhb>
btw. clever why are you writing your own firmware?
<clever>
eyJhb: to replace the closed-source firmware, and open up the option of making the VPU do more jobs
<eyJhb>
clever: no one has done that so far?
<eyJhb>
Also, do you have anything up atm?
<clever>
eyJhb: there is a repo on github, that claims it could boot linux on an older rpi
<clever>
eyJhb: but i had to mod it for a week before i could get it to boot to a usable shell
<clever>
currently, linux can boot to a shell over the serial port, and the SD card adapter works, thats it
<clever>
i'm also testing on the rpi4, but that one isnt able to bring the arm cpu online
<eyJhb>
Hmm, seems like a tricky task. guessing you have experience in the field?