57200+ entries in 0.395s
mircea_popescu: i am all for keepiong the unrolled version at the ready ; but i really see no problem with having and using the unrolled loops version. you read it once, over
a weekend or
a week, and you use it ten billion times over fifty years.
mircea_popescu: honestly i don't believe the somewhat more cl is such
a problem.
mod6: <+erlehmann> something involving
a goedelized perl script that builds all build rules that don't build themselves. drugs were probably involved. << dafaq is this dude on about?
mircea_popescu: and finally re crc : given
a string S of any length, the probability of
a string S' where less than 32 bits have been altered in
a "burst" passiong crc32 is 0. if you go over 32 bit long bursts the probability is ~ proportional to the burst length / 32.
a111: Logged on 2017-08-09 15:58 mircea_popescu: anyway, let it be said that there's nothing wrong with oaep as far as we know, but for the sake of argument
a mpfhf based padding scheme would conceivably work like this : 1. given message m, of length l, generate r = random bits, of length l' up to l but not less than 256 bits. 2. compose m' = r + m + c (in that order), where c is l - l` (and its bitness is always same as the bitness of len(m')-256). 3. compose Pm = R + S +
mircea_popescu: reversing MPFHF is not required for the above quoted version, as the fhf is used there as
a hash function not as
a padder. (and alf's objection is valid, not
a very good option,
a settable size output sponge would be much better).
mircea_popescu: !~later tell peterl the hash-xor thing is oadp, which is
a provedly strong padding scheme for rsa.
PeterL: Is there
a way to calculate the probabilty that
a random string of 256 bytes will pass
a csc check?
PeterL: and wouldn't you also need to know S if you are going to reverse the MPFHF from
a given R?
a111: Logged on 2017-07-18 18:23 mircea_popescu: asciilifeform understand this bit of GT : the knowledge of all the things you don't know thereby constructs
a sybil of you.
pa1atine: hi all, great reads I had those days. logs are
a trove of wisdom
mircea_popescu: but isn't it great that all mgm needs to do is to put on
a coupla hats and suddenly the turnips think themselves human fucking beings ?
mircea_popescu: in other lulz : obviously there's
a "foundation" and
a "code of conduct" (the usgistani nonsense copy/pasted) and
a freenode chan, why not. ~600 accounts logged in (specifically :
http://p.bvulpes.com/pastes/yDU6G/?raw=true ) , ZERO anyone has to say at all whatsoever. most are related to matrix.org, which is
a pile of nonsensical lulz which you're more than welcome to try and make sense of by yourself. in any case, it's an "
☟︎ mircea_popescu: hanging out with any other troop of stoners would be
a better use of your time, in the sense of variety.
mircea_popescu: nobody knows what the fuck "sha 2017" is. nobody cares. even the people paid to fucking care stopped giving
a shit in the 90s, as that nsa goon at "crypto conferences" piece amply attests.
mircea_popescu: "tell that to some guy
a little younger than you, who just fell off the turnip truck. there is no publicity value in my talk being at your conference. what, if you sell 2000 of them it'll be
a miracle. and what, what are people going to say, uuuuuu i like how that erlehmann talks, i wonder if he's got
a blog or anything".
erlehmann: maybe i am not clear enough: i did not get to hold
a talk so i talked to random c developers for fun.
erlehmann: one lulzy consequence is that
a lot of software might have been released with sublty wrong header files included
erlehmann: mircea_popescu i wanted to give
a talk about non-existence dependencies at SHA 2017 and it was rejected with “provide
a 5min lightning talk on problem instead”. problem: 5min are enough to understand the problem, not why you are having it or what follows from it.
mircea_popescu: asciilifeform i guess when he comes back from the mpfhf reverser ima make him do
a keccak impl that ACTUALLY does the any-output thing. afaik they're all 32/64byte
erlehmann: 2. yes, this might be
a problem for some, but it never happens to me
erlehmann: 1. this is not
a problem at all in my process
mircea_popescu: asciilifeform most importantly, do we ACTUALLY want to do something pgp-retarded like say R.len = 200 bytes, repeat the last 50 for
a 250 byte total then use the repeat to make sure you decrypted correctly ?
erlehmann: mircea_popescu one person hallucinated having seen the elusive djb redo c code that ultimately did not exist. another person was
a release manager and made sure the problem does not exist.
a third person wrote
a cmake thingy longer than my own redo implementation.
a freebsd developer confirmed the problem exists.
erlehmann: something involving
a goedelized perl script that builds all build rules that don't build themselves. drugs were probably involved.
erlehmann: the solution turned out to be
a non-solution btw
erlehmann: asciilifeform correct. the talk begins with me mentioning non-existence dependencies and ends with the recipient either having
a solution (one guy), being aware of the problem already (i counted two) or being unaware of it but being aware that their software is
a lie.
mircea_popescu: erlehmann it's
a pile of patches. how the compiler optimizes the rebuilding is irrelevant ; if you change one file it can rebuild the whole thing or not ; but v still only changes the one file and still doesn't have the problem.
erlehmann: mircea_popescu in
a way, it does. no?
erlehmann: asciilifeform C header files are only one instance of such non-existence dependencies where existing of
a thingy invalidates the assumptions that went into building another thingy.
erlehmann: asciilifeform that is one possible answer to the think. the thing that starts the triggering is usually
a combination of said devs using make and realizing that this is, indeed,
a problem.
erlehmann: if
A or B start to exist, the target also needs to be rebuilt. that is
a non-existence dependency.
erlehmann: if C changes, the target needs to be rebuilt. that is
a dependency.
erlehmann: asciilifeform on systems with multiple include paths,
a C or C++ header file is looked for in location
A, B, C. it is found in directory C. it does not exist in location
A or B.
mircea_popescu: otherwise why implement
a ptron rather than simply
a rsatron.
mircea_popescu: pubkey crypto dunb enter into it, this is
a discussion of signature hashing (digests, really) schemes.
mircea_popescu: the statement is that if pss is used atop rsa, then baring poor implementation
a forgery is going to cost more than what reversing rsa costs.
mircea_popescu: it's incomprehensible to me, how this "i moved from
a forum to
a ... forum" thing works in the public's mind.
BingoBoingo: Not really made
a blog. Started making posts on platform that it seems some other folks made.
a111: Logged on 2017-08-01 23:43 mircea_popescu: i suspect steemit is
a sort of how did they call that alt-disqus/alt-github "let us steal your content" thing ?
mircea_popescu: (ftr, the way pgp does it is that it repeats two bytes of
a more or less random block of 16 bytes, and then checks if they came out the same. this is in fact WORSE than
http://btcbase.org/log/2017-08-09#1696023 but then again contemporary applied cryptography is
a very low effort, low quality field).
☝︎ mircea_popescu: so you want to take
a message m, add that many random bits to it, and then add twice that many bits as
a hash of the pile, thereby using 25% of the space for the plaintext ?
mircea_popescu: trying to stuff
a mac or something in there will make the bondogle regret the days of the aes/rsa combo.
mircea_popescu: asciilifeform yes, well, everything has problems. but there's
a difference between using
a crc as hash and using
a crc as checksum ; and using say sawed-barrel keccak (take first or last x bytes, whatever) isn't all that good because it's really not designed for fragment behaviour like that, nor was such studied
PeterL looks, finds
a .py standar lib function for this: binascii.crc32
PeterL: suggestions on
a good hash function for
a checksum?
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: up to the limit of the size of
a udp packet?
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: and so thereby
a 4096 bit key can handle chunks of up to 512 bytes of message.
PeterL: so each character must have
a value less than the n it is using, right?
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
PeterL: because you are calculating
a number mod n, so the result will therefore be smaller than n
mircea_popescu: had there been
a wrap, i couldn't have extracted the cube root [quite so easily]
mircea_popescu: short messages are
a problem for rsa, not
a boon. this is generally fixed by padding.
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.
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: and if we are sending to key
A and B, we will need 1024 bits for each segment anyway
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: erlehmann so what, you're of
a firm "will only work for evil empires" persuasion ?
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: 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)?
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: mircea_popescu suggested instead using
a checksum