160300+ entries in 0.051s
mircea_popescu: which was the original fucking point that ended up in all this weird.
mircea_popescu: asciilifeform otp bias cheifly doesn't matter here, as the same otp is delibverately used for both messages.
mircea_popescu: thus nth position in otp xor nth position in ciphered a must yield n and in ciphered b must yield 65535-n
mircea_popescu: first plaintext counts up from 1 ; the 2nd counts down from 65535
mircea_popescu: now, 64kb aren't that much, and the structure chosen is literally the simplest thing available for ease of implementation. nevertheless, a little DOES leak even so.
mircea_popescu: the method described above, one plaintext counts up one counts down.
mircea_popescu: assay 4 : count 32810 / 32814. expected 1st lower than 2nd. confirmed.
mircea_popescu: assay 3: count 32959 / 32964. expected 1st lower than 2nd. confirmed.
mircea_popescu: assay 2 : count 32778 / 32775. expected 1st lower than 2nd. infirmed.
mircea_popescu: assay 1 : count 32734 / 32743. expected 1st lower than 2nd. confirmed.
mircea_popescu: you can make as many otps as you want, it's still coming out the same way o.O
mircea_popescu: ok i guess ima have to figure out some way to hm. hey asciilifeform , how about this deal : i pay you 10 btc of my eventual winnings, should they exist, but you make the messages and show the result. i dun have a compiler ready and nfi how you generate the described messages in bash
mircea_popescu: han byte n-1. The larger of the two indicates the message encrypted ; the difference between these counts indicate your confidence (or the rng's bias).
mircea_popescu: asciilifeform : Let message A consist of individual bytes counting down from FFFFFFFF ; let message B consist of individual bytes counting up from 00000000. Let the enemy xor one of these two against a random, unbiased OTP of the same length and supply the enciphered result. Take that result, and count the instances where byte n is larger than byte n+1. Take that result, and count the instances where byte n is larger t
mircea_popescu: that i guess your message. which i suppose necessarily carries the caveat that "must not be by chance",
mircea_popescu: asciilifeform notice that this isn't "wins/loses". you're just giving 10 btc away, on the if.
mircea_popescu: mk, ima bbl see if i can hack together something that satisfies the audience theoretically.
mircea_popescu: it really needn't be done over more than one try lol. srsly ? 1k ?
mircea_popescu: you don't see the crc discussion sufficient for our purposes ?
mircea_popescu: and if the plaintext is long enough, this is equivalent to a requirement of minimal bias in the otp pad.
mircea_popescu: but in general, if you do away with the requirement to recover ALL of the plaintext,
mircea_popescu: how biased the otp needs to be is part of the crc spec, for instance "every 8th bit may be a 1" etc.
mircea_popescu: let me put it this way : stuff like CRC, or ECC etc, exists fundamentally out of "we guarantee you can recover the plaintext after it has been otp'd with a pad which is AT LEAST this biased"
mircea_popescu: the examples given are not structured and readily reduce to "1" and "0", so no, it wouldn't work here.
mircea_popescu: you'll fucking see which one is encrypted in five minutes.
mircea_popescu: if you're making 1 mb of 01111110 and 1mb of 10000001 and then otp them against a random pad
mircea_popescu: asciilifeform funny how money clears the mind, even if it's too little to mention.
mircea_popescu: punkman why, he didn't feel obliged to add any btc to the other one, just bitch about the insufficiency of the sum.
mircea_popescu: you pick one of two lengthy, structured plaintexts i provide, you encrypt them with a biasless, purely random rng, and i decide which of the two you picked.
mircea_popescu: are you paying me 10 btc if we do this experiment and i do guess it, "with telepathy, at home" ?
mircea_popescu: they aren't all equally probable if i can rely on your otp being random.
mircea_popescu: if i know you will be encrypting one of shakespeare's plays, otp won't save you.
mircea_popescu: there is another way to die using otp, and that way is to use a lengthy biased message the enemy knows most of.
mircea_popescu: this alone should show they're deeply inadequate, but who knows fundamentals anymore.
mircea_popescu: asciilifeform technically speaking, the s-box cipher crapolade is an ellaborate exercise in reusingselect parts of otp
mircea_popescu: understand : if you collect say 1024 random bits, the chances of seeing 512 1s and 512 0s are < 1%
mircea_popescu: to be plainer : otp works better with biased pad of unknown bias than with unbiased pad of known lack of bias.
mircea_popescu: this is actually usable to describe a lot of the plain text, and exponentially more so when i know that debug.log tends to contain a lot of "connection" strings.
mircea_popescu: now, those 4 cases out of 8 of "10" have equal chances to meet 00, 01, 10, and 11. as a result you will see :
mircea_popescu: let's work with a very simple example. suppose we use two bits, and suppose the plaintext is as follows : 00 appears 1 case out of 8 ; 01 appears 2 cases out of 8 ; 10 appears 4 cases out of 8 and 11 appears one case out of 8. 1+1+2+4=8.
mircea_popescu: punkman "items" is used there deliberately, to scale with the size of the block you use.
mircea_popescu: this is an operation very close to compression, a sort of crypto-lzw.
mircea_popescu: the correct way to apply otp to something like human readable text is to weigh it.
mircea_popescu: and yes as noted by alf the "pill" for this fundamental problem is to make sure that message length stays well under statistical sample.
mircea_popescu: this is fundamental instruction in the importance of.... large block sizes.
mircea_popescu: the necessary result is (different items have same varying, known probabilities to appear as in the plaintext)
mircea_popescu: you're doing (items have varying, known probabilities to appear) xor (all items have same probability to appear).
mircea_popescu: perfect noise = all items have exact same probability to appear.
mircea_popescu: to be studied in pairs, one kid makes the scheme, the other kid breaks the scheme, then alternate positions.
mircea_popescu: do the experiment for yourself, it's really a great entry thing into cryptanalysis.
mircea_popescu: esp since i know plenty of strings likely to appear in the plaintext.
mircea_popescu: i will then proceed to count the As and the Ws and break your thing to a large degree.
mircea_popescu: for instance, consider the naive situation where you take 1mb worth of debug.log, and xor it against 1mb of perfect noise.
mircea_popescu: the whole power of the scheme comes from "everything's equally likely". yet if everything's not equally likely...