168300+ entries in 0.102s
PeterL: still better
than
twitter, I guess
PeterL: but
that 256 also has
to carry stuff like user name
mircea_popescu: so your gossiptron only accepts lines of up
to 256 chars in length,
then you lzw
that and pad etc. not
the end of
the world.
PeterL: the other optin would be
to use rsa keys of half
the size, allowing only 256 byte messages
mircea_popescu: as alf says : "something
to all comers". primo
target of ddos monkeys.
mircea_popescu: but even if you send
them "together",
there's no guarantee
they stay unfragmented. not at
that size.
PeterL: if
they did not come
together in one packet,
then you would have
to hold onto packets and
try
to match
them up with
their partner
PeterL: mircea_popescu: but encrypting
the r
to one key and
the r xor m
to a second key, so you end up with
two rsa-key-length segments
mircea_popescu: PeterL what is
the scheme contemplated here,
that you
take a say 8 byte message, generate an 8 byte r,
then create a 16 byte padded message by appending
the r and
the r xor m and
then rsa
that ?
PeterL: which would mean using keys of half
the size, right?
PeterL: please, help me see
the flaw?
PeterL: up
to
the limit of
the size of a udp packet?
PeterL: and my scheme splits messages into r and m xor r, so I need 1024 bytes
to pass
the smallest message, which is already larger
than
the UDP "unfragmentation limit" of 512 bytes, so why stop
there and not just let
the message get longer by adding in some more chunks?
mircea_popescu: (the precediny line was 146 characters, which is less
trhan 146 bytes, especially if you do a lzw or something like sane people first)
mircea_popescu: PeterL and as asciilifeform aptly points out,
this happens
to be convenient, because it's right around
the size of
the nonfragmenting udp packet.
mircea_popescu: and so
thereby a 4096 bit key can handle chunks of up
to 512 bytes of message.
PeterL: so
the message is larger
than
the key modulus, part of it will be lost when it is decrypted
PeterL: so each character must have a value less
than
the n it is using, right?
PeterL: it looks like
this
thing is encrypting each character individually?
mircea_popescu: do an example once, it's instructive. easy
to follow because small numbers.
a111: Logged on 2017-08-09 14:24 mircea_popescu:
https://www.ti89.com/cryptotut/rsa3.htm << very handy rsa
tutorial in
that it uses base 10 and alphabet-indexing for letters. so one can actually rsa by hand and get a good model of what's going on.
PeterL: because
the decryption is also a calculation mod n
PeterL: so you can't use a number larger
than n
mircea_popescu: that
the result is smaller
than n is of no consequence
to you is it.
PeterL: because you are calculating a number mod n, so
the result will
therefore be smaller
than n
PeterL: alright, so my scheme pads everything
to
the length of
the key, but as I understand it still has
to be smaller
than
the key n?
mircea_popescu: but in any case,
the point is -- rsa is not better for shorter messages. for really short messages it can be really shitty. which is why my 256 minimum bits in
the padding scheme.
mircea_popescu: PeterL yes,
there is
that. larger e provides some protection agaisnt
this issue.
PeterL: right, I understand
that part
mircea_popescu: had
there been a wrap, i couldn't have extracted
the cube root [quite so easily]
mircea_popescu: that's what i meant earlier with
the e-root. if say your key is 1024 bits, and your exponent is 3, and your "encrypted" message is, numerically, 1404928, i can readily extract
the cube root and find
the original as 112.
PeterL: I
thought it was only bad if m^e was less
than n?
mircea_popescu: short messages are a problem for rsa, not a boon.
this is generally fixed by padding.
PeterL: hmm, no, it would have nothing
to
transpose
to
mircea_popescu: now, intuitively, would you imagine
this worked at all if
the string was so short it never fully wrapped ?
PeterL: alright, so
the decryption relied on having an identical physical object?
mircea_popescu: basically
they had
this early elliptic curve crypto, implemented as an arbitrary cone on which
they wrapped a string. because
the string is fixed length see, whereas
the section of cone is not.
☟︎ mircea_popescu: well cesar was a roman, wasn't he ?
the "technologically advanced" dorks
that
took
the sail
tech of
the people who sailed from sweden
to south africa and made some square sailed
tubs
that sunk in
the mediterranean half
the
time.
PeterL: not really,
the ceasar cipher or something?
mircea_popescu: PeterL can you
tell me anything about what
the greeks used for encryption ?
PeterL: c^d mod n = m,
therefore m must be smaller
than n?
mircea_popescu: pro
tip : it is always a very useful
thing
to be able
to reflect your own mental process, which starts with being able
to answer "where i got
this from". makes error handling much faster and infinitely more efficient.
PeterL: 4096 bit key n, message needs
to be smaller
than
that, right?
mircea_popescu: PeterL let's get back
to cogency here. how did you come
to
the "512 rsa packet limit" ?
PeterL: and if we are sending
to key A and B, we will need 1024 bits for each segment anyway
mircea_popescu: im guessing i'll be
taking ads in
the local newspaper, "looking for lawyers willing
to sue
the government, apply within".
mircea_popescu: b)
they want
to... "know your customers". bitch, it's none of your fucking business ? uh no, because ley so and so say so.
PeterL: well, udp packet is alot bigger
than
the 512bytes
that fit in a rsa packet, why waste all
the space?
mircea_popescu: in other lulz, /me went
to open bank account
today. you can not BELIEVE how fucking pussy whipped
these people are. a) bank's only wire intermediary is bank of america. why ? uh...
that's what
the other banks do
too. but... why ? umm... is it because you schmucks are a us colony, in
the sense you don't get medicare and
they still get all your shit anyway ? uhhhh
mircea_popescu: because udp packets if nothing else ; besides "longer" is not
the same as endless.
erlehmann: mircea_popescu it feels like work. i had
that experience a few minutes ago, when i explained
to a rando on
the
train
the concept of non-existence dependencies.
PeterL: but I want
to make longer messages possible
mircea_popescu: PeterL
the cutting into chunks should happen prior at some client level. it's ok if your
think accepts no messagtes lonmger
than x. irc doesn't either.
PeterL: so for longer messages,
they will get cut into chunks. It it better
to check
the first chunk until you find
the right key and
then use it
to dercypt
the whole message, or do you want
to decrypt
the whole message with every key (to hide
the fact you found a match)?
mircea_popescu: don't even have
to, but consider
the context. yes "it's what rsa is",
that's what i'm checking,
that he knows.
PeterL: I am still learning here,
the last
time I came and said "how do I know if I have used
the right key
to decrypt it?" nobody suggested a checksum, now I will
try
to figure out how
that would fit into
the program
PeterL: who am I
to stop people from sabotaging
themselves?
PeterL: It checks
to see if it is using
the right key by comparing
the decrypted
text agains a pre-known challeng-string (cs)
a111: Logged on 2017-08-09 14:12 PeterL: using
the wrong key will result in a random byte string, so with a cs of 1 byte, you have 1/256 chance of looking like it was
the right key
PeterL: right, my scheme was doing
that
a111: Logged on 2017-08-09 14:14 mircea_popescu: so you are
telling me
that m ^ e ^ d mod n always has an integer solution for randomly chosen parameters.
mircea_popescu: but yes, for unrelated reasons fixed size is
the right choice for gossipd.
a111: Logged on 2017-08-09 14:11 PeterL: if you have a 0 byte cs,
then every message looks good
PeterL: so not more
than rather
than not less
than 256
mircea_popescu: and rnd(256, l) is not equivalent because who
the fuck knows what rnd does when a > b.
PeterL: mircea_popescu: if l is less
than 256,
then l' = 256?
PeterL: I will have a look at making a reversing function for
the mpfhf