2000+ entries in 0.444s
punkman: where is this znc
otp plugin?
jurov: kek. but it's true somebody here sponsored
otp for znc plugin
phf: somebody here i believe sponsored
otp for znc plugin
mircea_popescu: (meanwhile i asked for the why and wherefore of the "debiasing" of the plaintext. "no you idiot, it's so you burn less
otp. what the fuck's wrong with you!")
mircea_popescu: the recent debias-
otp-plaintext thing being a splendid if amusing example in this exact line.
assbot: Logged on 08-02-2016 02:23:29; phf: for extra lulz paper includes proof of
otp perfect secrecy taken from a coursera cryptography course
phf: for extra lulz paper includes proof of
otp perfect secrecy taken from a coursera cryptography course
☟︎ phf: ;;later tell maqp on a cursory inspection i couldn't figure out how the protocol decides between
otp and cev, how those are identified on the wire, etc. is that up to the user?
phf: ;;later tell maqp if i were you i'd split tfc.pdf into separate papers. HWRNG, data diode communication, tfc
otp, tfc cev and "rationale", the last one to include all the superfluous NSA shoutouts
punkman: "why use information theoretically secure ciphers" << not really plural there, there is only
otp maqp: basically it's like
OTP but with forward secret cascading encryption
maqp: It's also a lot easier with NaCl than with
OTP/CEV (there's a separate command for adding PSKs)
punkman: maqp, is that a carter-wegman MAC in your
otp version?
maqp: thanks. I wanted to recommend you guys take a look at the TFC-NaCl that's fresh out of oven and has better design compared to
OTP/CEV versions
mircea_popescu: you're the guy with the open source
otp / airgapped thing are you ?
punkman: the
otp implementation is possibly decent though
punkman: /me goes look for
otp-compatible MAC scheme
punkman: you can't get the bitmap penguin after
otp 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
punkman: what's the point of public
otp punkman: mp must guess how many of the 100 ciphertexts are made from the string ""mircea_popescu: long, deeply biased plaintexts are dangerous for
otp.""
punkman: other variant: ascii makes 100 otps, makes 100 plaintexts, X of which are the string "mircea_popescu: long, deeply biased plaintexts are dangerous for
otp.", then passes 100 ciphertexts to mp. mp must guess X withing some range.
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
punkman: you pick one of 1000 plaintexts, generate one
otp punkman: mp makes 2 plaintexts, ascii generates 1000 otps, for each
otp: picks one of the 2 plaintexts and xors with
otp. mp must guess guess correctly 501?, 600? more?
mircea_popescu: and if the plaintext is long enough, this is equivalent to a requirement of minimal bias in the
otp pad.
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: if you're making 1 mb of 01111110 and 1mb of 10000001 and then
otp them against a random pad
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: asciilifeform technically speaking, the s-box cipher crapolade is an ellaborate exercise in reusingselect parts of
otp punkman: you can't do frequency analysis on
otp punkman: isn't compressing your
otp akin to whitening?
assbot: Logged on 03-02-2016 01:53:21; asciilifeform: actually for many years i have thought about the ideal electric
otp.
mircea_popescu: to be plainer :
otp works better with biased pad of unknown bias than with unbiased pad of known lack of bias.
punkman: this sounds like you want to do frequency analysis on
otp, but perhaps I'm just thick
mircea_popescu: the correct way to apply
otp to something like human readable text is to weigh it.
BingoBoingo: <punkman> gotta have something to remember how much of the
otp has been used << burn the used pages of your cipherbook
punkman: gotta have something to remember how much of the
otp has been used
BingoBoingo:
otp implementation is as good as your random
punkman: is there a decent
otp implementation?
ben_vulpes: what does c-s buy one over the
otp in that case?
mircea_popescu: in the EP? general scheme of true cryptography,
otp occupies a peculiar spot, equivalent to rsa's use of multiplication, where
otp uses "multiplication modulo 1" or "multiplication in the binary group" for a º function
ben_vulpes: and the need to share the key does not impose the same operational considerations as
otp?
ben_vulpes: cramer shoup + shared key does not reduce to...
otp?
mircea_popescu: asciilifeform>
otp. << if the key is 64kb, technically
otp would work fine for message up to 64kb.
mircea_popescu: anyway - it's not that i don't like paper
otp, or
otp generally. it's that if that's the best you can do, you should have been a clockmaker