log☇︎
1500+ entries in 0.279s
deedbot: Get your OTP: http://p.bvulpes.com/pastes/SXtpB/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/Mfhbr/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/QXdU2/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/aC964/?raw=true
asciilifeform: a clever buffering scheme would work mircea_popescu-style, by sending otp rngolade during idle pauses in conversation, and thereafter using.
deedbot: Get your OTP: http://p.bvulpes.com/pastes/WYvmi/?raw=true
mircea_popescu: basically the scheme is, you rsa a random bitfield, then you expand that into as much otp as you want by doing recursively Fi = hash(bitfield + Fi-1). there's a limit on i, obviously, which can be set to 1. ☟︎☟︎
asciilifeform: otp reused once is broken.
deedbot: Get your OTP: http://p.bvulpes.com/pastes/10DsF/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/gEl7P/?raw=true
asciilifeform: if he fails to silently break even ~one~, you have a working otp !
asciilifeform: mircea_popescu: another hypothetical 'near solution' would be a well-boobytrapped package containing remanence-free ( per http://btcbase.org/log/2017-05-16#1656777 scheme ) sram with otp ☝︎
mircea_popescu: i don't get it. so you get hdd 1, make 5 copies, i capture one, start grinding it into an otp. so do you. if my computer is 10% faster i'll have the i+1 10% faster than you will.
asciilifeform: consists of 1) an ordinary, trivially copied otp, e.g. a hdd full of fuckgoatsolade ;
mircea_popescu: you make otp 1 and 2, and send 2 to china. i take 2 and make 3 and 4, pass off 3 as 2 and keep 4.
asciilifeform: i.e. an otp that is intrinsically safe to transport.
asciilifeform: ( i.e. can you make a matched pair of otp such that 1) output is cryptoentropic 2) can only leave the device at particular baud rate , no matter what is done to it ? )
asciilifeform: originally asciilifeform's interest in subj, will confess, was re 'uncopyable otp'.
deedbot: Get your OTP: http://p.bvulpes.com/pastes/ZCreA/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/M5dKx/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/gmaQc/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/dYUDW/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/ibBmP/?raw=true
elaineo: i got the OTP through PM
asciilifeform: sane discussion of the question, followed by an answer you can go with ( because if it turns out that oneway functions do NOT exist, all crypto other than otp is worthless )
asciilifeform: the thing is, 'knows answer ahead of time' is not an all-or-nothing. in any non-otp ( i.e. 1:1 mapping of plaintxt to ciphertxt ) there is nonzero bittage of info in ciphertext, of plaintext
asciilifeform: incidentally i just realized that von neumann had this thread. and modelled the item in shannon's terms : he asked that the ciphertext contain 0 bits of info re the plaintext. and proved that this is true if and only if you're using... otp
a111: Logged on 2017-09-28 09:39 mircea_popescu: not necessarily the specific example. but yes, symmetric cipher always reduces to a "parametrized otp".
mircea_popescu: not necessarily the specific example. but yes, symmetric cipher always reduces to a "parametrized otp". ☟︎
mircea_popescu: to voice self say !!up to deedbot in pm, then decrypt the thing he gives tyou and say !!v to him with the otp
deedbot: Get your OTP: http://p.bvulpes.com/pastes/uWgqM/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/IiHuI/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/LNTYv/?raw=true
asciilifeform: which means that even a minute-long modexp is theoretically fieldable ( you get ~day-long keygen, and minute-per-4096bits decrypt/encrypt, but this is livable, ancestors lived with much slower hand-cranked otp )
deedbot: Get your OTP: http://p.bvulpes.com/pastes/FYTXm/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/YVgGQ/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/HEa8i/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/dwVPT/?raw=true
trinque: the thought re OTP is if I don't force people to verify one, I'm letting allcomers generate "chosen-plaintext" for a particular key
deedbot: Get your OTP: http://p.bvulpes.com/pastes/MCR2U/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/c1stg/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/b6NyJ/?raw=true
asciilifeform: ( if making own 'disks' -- use otp roms for blockchain. as discussed in old thread. now if only somebody still made otp roms !! )
valentinbuza: i saw, OTP is one
a111: Logged on 2016-05-31 19:51 asciilifeform: not a single symmetric cipher other than otp has ever been proven to be worth a sparrow's fart.
deedbot: Get your OTP: http://p.bvulpes.com/pastes/WNenm/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/u3P5B/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/7Ygyf/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/mo4Ow/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/lAVCu/?raw=true
mircea_popescu: but outside of this, "has T told X about Y's otp" is very much a "you wouldn't download a car" type of problem.
a111: Logged on 2017-08-06 05:36 mircea_popescu: trinque re last para, what's wrong with you know, http://btcbase.org/log/2017-08-03#1693444 ? basically replace "The user decrypts the ciphertext and returns the cleartext OTP to D, which relays it to T, meanwhile revealing it to L. T replies to D with either "OK" or "FAIL", and a transaction is complete." with "T sends hash(C) to L, encrypted(C) to D. The user decrypts the ciphertext and returns the cleartext OTP to D, which
a111: Logged on 2017-08-06 05:36 mircea_popescu: trinque re last para, what's wrong with you know, http://btcbase.org/log/2017-08-03#1693444 ? basically replace "The user decrypts the ciphertext and returns the cleartext OTP to D, which relays it to T, meanwhile revealing it to L. T replies to D with either "OK" or "FAIL", and a transaction is complete." with "T sends hash(C) to L, encrypted(C) to D. The user decrypts the ciphertext and returns the cleartext OTP to D, which
trinque: http://btcbase.org/log/2017-08-06#1694432B << does this render the question of whether T leaked user 1's otp to user N moot? if so I'm not seeing it yet. ☝︎
mod6: mike_c: it's now ``!!up'' and ``!!v <OTP>''
deedbot: Get your OTP: http://p.bvulpes.com/pastes/WQBqO/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/brgvw/?raw=true
PeterL: and so it uses your proposed "virtual otp" straight rsa encryption
mircea_popescu: http://btcbase.org/log/2017-08-05#1694272 << you've looked at these neh ? it's a very strict format, first line the command, 2nd line the otp. what last year's codes fits this format ? ☝︎
mircea_popescu: relays hash(it) to T and L. T replies to D with either "OK" or "FAIL", and reveals (C) to L. L calculates hash(OTP) and compares it with what D sent."
mircea_popescu: trinque re last para, what's wrong with you know, http://btcbase.org/log/2017-08-03#1693444 ? basically replace "The user decrypts the ciphertext and returns the cleartext OTP to D, which relays it to T, meanwhile revealing it to L. T replies to D with either "OK" or "FAIL", and a transaction is complete." with "T sends hash(C) to L, encrypted(C) to D. The user decrypts the ciphertext and returns the cleartext OTP to D, which ☝︎☟︎☟︎
a111: Logged on 2017-08-05 20:09 deedbot: http://trinque.org/2017/08/05/otp-bot-services/ << trinque - Towards a Reliable OTP Mechanism for Bot Services
deedbot: http://trinque.org/2017/08/05/otp-bot-services/ << trinque - Towards a Reliable OTP Mechanism for Bot Services ☟︎
trinque: in order for a log of OTPs to be meaningful, in that it asserts a particular person assented to an action at a given time, gotta know the OTP corresponds to the item sent to that person. the way I've been thinking about that is encrypting the OTP with two keys, one of which I hold; the other belonging to the outside party
trinque: ah now I recall what might reduce the print audit's usefulness. it means visual inspection of the encrypted items, as well as OTPs. logger box has to first see the encrypted item, second, corresponding OTP, and then this log has to be verified by someone who can (elsewhere) crack open the encrypted ones and match up the OTPs.
trinque: funny thing was I'd already considered having the OTP box burn a CD as it went along, just shitter printing without visual inspection.
asciilifeform: thermal tape shitter is also great for otp btw
a111: Logged on 2017-08-03 17:41 trinque: if there were a hardware-only way of logging what traveled over that serial port, even better. that'd be the audit trail instead of the OTP box's disk.
trinque: if there were a hardware-only way of logging what traveled over that serial port, even better. that'd be the audit trail instead of the OTP box's disk. ☟︎
trinque: ah probably string of command, since folks need to see what it is they've gotten an OTP for. at any rate, still not branch-causing.
trinque: otp box can be msdos over serial port, input parsing is trivial (key parameters, hash of command; so all numeric - none causing branching)
trinque: the otp part discussed here stands alone, though. a rather dumb piece of software can keep track of encrypted OTPs it dispatched, the corresponding command (which sits in the encrypted item), and when it got the OTP back.
trinque: otp generator can keep an audit trail, which can be run out of band when moving actual coin.
deedbot: Get your OTP: http://p.bvulpes.com/pastes/tqGg1/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/FqD8c/?raw=true
trinque: http://btcbase.org/log/2017-07-14#1683508 << apologies, this is going to take another weekend. the bot wallet service is done, but it occurs to me that it'd be wise to separate the OTP generation from the rest of the services. on one side, a big, complicated wonder of modern computing; on the other, a simple box connected by serial port which can receive OTP requests, generate them, and confirm/ignore OTPs. ☝︎
deedbot: Get your OTP: http://p.bvulpes.com/pastes/GTYPE/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/7oCw1/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/Z4Kkm/?raw=true
asciilifeform: i still reel from the riotous idiocy of even calling a public string 'an otp'
deedbot: Get your OTP: http://p.bvulpes.com/pastes/178XC/?raw=true
asciilifeform: just say no to faux otp, folx
asciilifeform: so nao naturally they'd like to trick some idiot, somewhere, into using their pre-indexed fauxotp as an otp...
asciilifeform: 'The advantage of this method is that a binary random sequence of any length can be easily generated from public or private genetic databases. An unlimited number of distinct random sequences can be obtained by multiplexing, shifting or concatenating sequences from different DNA species. To solve the major drawback of the OTP cryptosystems, key storage and transmission, Borda et al. proposed communicating the secure key through the s
daffadil: This might be interesting to some: "DNA based Random Key Generation and Management for OTP Encryption"
deedbot: Get your OTP: http://p.bvulpes.com/pastes/BxfrQ/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/WuFpQ/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/BDRoP/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/VcJZl/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/5t0oL/?raw=true
deedbot: Get your OTP: http://p.bvulpes.com/pastes/4EZae/?raw=true
asciilifeform has searched, in vain, for otp rom in useful capacity for years nao
mircea_popescu: it is similarily possible for last bit of xor otp to flip only last bit of r.
sina: I assumed it was deedbot style OTP thing
sina: I was just happy to get the OTP working for today and will continue to increment it
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.
deedbot: Get your OTP: http://p.bvulpes.com/pastes/Oxgfk/?raw=true
daffadil: +mircea_popescu so I don't need to do anything with that deedbot OTP message?
daffadil: don't understand the "Get your OTP" message from deedbot, whose key encrypted it?
deedbot: Get your OTP: http://p.bvulpes.com/pastes/EcjkV/?raw=true