2100+ entries in 0.174s
mircea_popescu: "what do you think 4Gz means, bitch ? you do 4 billion
rsa per second."
mircea_popescu: in point of fact, this breadbox may qwell be clock-speed fast when doing
rsa, none of those second bs of python running on 8 bit "optimal" intel-me
sina: I just googled "small
RSA lib" and tomcrypt was one that had python bindings out of the box
sina: happy to swap out the
RSA lib if one can be proposed
mircea_popescu: the two main problems are the db and the
rsa import as it stands.
sina: cat .ssh/id_rsa.pub
mircea_popescu: so in this sense (not yet ready to shave the combined
rsa-symkey model) not ready to fly.
sina: but all traffic is sent as
RSA payloads with nothing at all in plaintext ever
a111: Logged on 2017-06-28 01:19 sina: in current model, operator can write a message and claim it is from anyone and "publish" it to their own message store. when peers connect, the messages since last seen are delivered, each encrypted with a peer-pair unique
RSA key. so as the message "progresses" between peers it gets encrypted, then decrypted and stored in each peers message store in plaintext
sina: "To craft a valid packet, a sender must collect a single auth string from the receiving node's lighthouse (via whatever means, can be a shortwave tuner), craft auth with it as described by Mircea Popescu earlier, encipher to receiver's
RSA pubkey, and send." ?
Framedragger: afaict gossipd model assumes that some
rsa keys had been exchanged out-of-band. traditional challenge-response has been constantly critiqued by asciilifeform via "it's a DoS vector" argument (sorry if too curt, am in bed)
Framedragger: right, eternal
rsa gen process,
rsa'd automatically, etc
Framedragger: asciilifeform: sure, but (plz don't vomit from use of keyword) there should be a way to onion-
rsa them, too (A encrypts to C's key, then encrypts to B's key and tells B to relay to C which is currently offline, or w/e)
sina: in current model, operator can write a message and claim it is from anyone and "publish" it to their own message store. when peers connect, the messages since last seen are delivered, each encrypted with a peer-pair unique
RSA key. so as the message "progresses" between peers it gets encrypted, then decrypted and stored in each peers message store in plaintext
☟︎ a111: Logged on 2017-06-27 00:57 asciilifeform: sina: one of the things gossipd needs is a constant-time-constant-space
rsa. if you don't have one, enemy can derive your privkeys remotely based on timing.
sina: asciilifeform: can you elaborate on timing? in my impl each peer-pair has its own set of corresponding
RSA keys and I was thinking of adding something like, at the end of each session a new keypair is generated and exchanged on each side
sina: alright. the gossipd thingo is 0.0.1 implemented. peers can communicate, each session (fetch messages) is mediated by deedbot style OTP with per peer-pair
RSA keys (no GPG shell asciilifeform, using libtomcrypt). I wrote a tiny client to add peers, exchange keys, broadcast msgs and view stored msgs. there is a README.
sina: any thoughts? does that even make sense? basically it's caused because I am trying to use a different pubkey per peer, if there was just 1 pubkey it would be a standard out of band
RSA pubkey exchange
sina: I am trying to program the following behaviour, a user can run "gossipc --add-peer --host 1.1.1.1 --port 5000 --name sina" and gossipc will select one of the available (not bogus)
RSA keys generated by the ongoing key generation process and say something like "peer added. advertise/exchange the following pubkey to that peer:"
sina: its not finished yet, but I just completed the "server" portion of the daemon the next piece is to start on the "client" that connects to peers, generates
RSA keys, sends bogus challenges
js-of-mp: except for asciilifeform who has no time for such things so instead he is writing a proper
rsa to be licensed by nsa to minigame so totally different.