00:03:52 -!- sftp has quit (Ping timeout: 244 seconds).
00:12:49 -!- sftp has joined.
00:29:52 -!- tromp has joined.
00:34:25 -!- tromp has quit (Ping timeout: 264 seconds).
01:14:37 -!- sprocklem has quit (Ping timeout: 246 seconds).
01:23:59 -!- tromp has joined.
01:26:10 -!- ais523 has joined.
01:26:39 <ais523> I wonder why there isn't a cryptographic hash designed to be collision-resistant, but intentionally not preimage-resistant
01:27:10 <ais523> the idea would be that posting such a hash would be a way of saying, effectively, "I want you to have access to the data that this hash is pointing to"
01:28:01 <ais523> I guess this is technically just a compression function, in the gzip/bzip2 sense, but it would also allow for, say, having the file stored somewhere on the Internet, together with a download URL and a cryptographic hash for verifying you had the right file
01:28:34 -!- tromp has quit (Ping timeout: 260 seconds).
01:29:40 <zzo38> Yes, magnet: URI does some of those things, but if you would have such a hash function available, you could use it in the magnet: URI maybe
01:32:26 <zzo38> Although I probably do not fully understand, anyways
01:35:55 <zzo38> It does seem like it would do what you said.
01:56:17 <shachaf> ais523: What's the benefit of not having it be preimage-resistant in that scenario?
02:18:08 -!- tromp has joined.
02:22:25 -!- tromp has quit (Ping timeout: 240 seconds).
02:24:00 -!- imode has joined.
03:12:07 -!- tromp has joined.
03:14:08 -!- moony has quit (Remote host closed the connection).
03:15:31 -!- iovoid has quit (Ping timeout: 272 seconds).
03:16:50 -!- tromp has quit (Ping timeout: 256 seconds).
03:19:11 -!- iovoid has joined.
03:21:37 -!- moony has joined.
03:36:23 <ais523> <shachaf> ais523: What's the benefit of not having it be preimage-resistant in that scenario? ← giving the hash to someone would be evidence that you wanted them to have the data, so there are no security implications of reversing the hash
03:36:42 <ais523> e.g., if you have a file on your system that matches the hash, you could safely give it to anyone who gave you the hash
03:38:14 <shachaf> I don't follow. Can't you just decide on that rule, if you want to use the hash that way?
03:38:40 <shachaf> If you have a 256-bit hash and a 256MB file, the fact that people can find a preimage (or even enumerate all preimages) doesn't help them get the file at all.
03:39:37 <ais523> someone having possession of, say, an SHA-256 hash of a file doesn't imply anything about whether they're supposed to have the file or not
03:40:09 <ais523> if the hash is designed not to be preimage-resistant, then possession of the hash does imply that you're meant to have access to the file
03:40:49 <ais523> because the person who made the hash has the file, and could have given it to them; and if they weren't meant to be giving access to the file at the same time, they would use a hash that was preimage-resistant
03:43:21 <ais523> the intended idea behind this, by the way, was for a hypothetical OS with much tighter permissions control than, say, Linux or Windows
03:43:27 <ais523> where programs only had access to what they needed
03:43:47 <ais523> the idea was that the programs could store some sort of hash for files that they didn't "own", allowing them to read them
03:44:23 <ais523> but that you would need to be able to prove that possession of the hash implied it was safe to give the possessor the file itself
03:45:32 <zzo38> O, OK. Now I understand (I think).
03:47:03 <int-e> So, hrm... you want capabilities that can be persistent?
03:47:09 <ais523> preimage-resistant hashes are often used to prove that you have a file without intending to give the file to the person you give the hash to, so in order to prevent it being used for that purpose, it has to be non-preimage-resistant
03:47:13 <ais523> int-e: yes, that's a good way to think about it
03:47:20 <ais523> like a capability for access to information
03:48:47 <shachaf> So you wouldn't actually use the non-preimage-resistance for anything?
03:49:48 <shachaf> It seems like you can just use SHA-256 for this, and only give people hashes of files if you want them to have access.
03:50:02 <shachaf> I guess you can use SHA-256 with a different starting state or something.
03:50:35 <zzo38> It seem to me that at least preimage resistance is not necessary for this case, but that a different hash is wanted to tell the difference of its use; I suppose SHA-256 with a different starting state might work, maybe
03:50:50 <int-e> Yeah, content-addressable memory is the other keyword that came to my mind.
03:51:22 <shachaf> I feel like I want there to be as few cryptographic primitves as possible and have them be simple and flexible.
03:51:51 <int-e> (where "memory" is generic, could be a file system, could even be a distributed file sharing thing))
03:52:32 <zzo38> (Is SHA-256 different-starting-state-resistance?)
03:52:50 <shachaf> When is NIST-or-whoever going to standardize an unkeyed permutation?
03:53:04 <shachaf> That seems like the best symmetric primitive to me.
03:54:36 <ais523> you could construct something like this quite simply, e.g. concatenate a file's SHA-256, SHA-1, MD5, and the first 16 bytes of the file
03:54:58 <ais523> that clearly leaks information about the underlying file, and is clearly at least as collision-resistant as SHA-256 is
03:55:14 <ais523> (the SHA-1 and MD5 make it easier to find random copies of the file that might be floating around online)
03:55:48 -!- sprocklem has joined.
04:06:29 -!- tromp has joined.
04:08:10 <zzo38> Yes, there is that. Does a magnet URI allow you to specify all of that stuff in one URI?
04:10:54 -!- tromp has quit (Ping timeout: 256 seconds).
04:11:03 <ais523> actually the magnet URI is the sort of thing I was looking for
04:13:03 <zzo38> I know that you can specify a single hash in a magnet URI, but I don't know if you can specify multiple hashes for the same file.
04:15:11 <ais523> it's not clear to me whether the format allows the same key to be given multiple times to give it multiple values
04:15:37 <ais523> also, there seems to be some sort of standardisation mismatch, you can specify an SHA-1 hash in a magnet URI with xt=urn:sha1:hash
04:15:47 <ais523> but sha1 is not an officially registered URN namespace
04:16:24 <zzo38> Yes, as far as I can tell no hash codes are officially registered URN namespaces
04:19:42 <ais523> I'm semi-seriously considering sending off a request to IANA to add some
04:20:57 <ais523> or two, sha1 seems to be most widely used for this, but we would ideally want a hash function that isn't broken as an option
04:21:03 <ais523> (or at least, isn't known to be broken)
04:30:42 <ais523> perhaps urn:sha1: wouldn't be accepted because of the potential for two different file to have the same URN
04:31:36 <ais523> it would need to be defined very carefully, e.g. saying that the URN referred to the only file in existence that had that hash at the time the URN was first created, and that creating such a URN is not valid if two different files with the same hash exist
04:36:46 <zzo38> I think that it could still work; the URN refers to the hash itself, not to the file.
04:39:29 <ais523> hmm, that's an interesting concept
04:39:36 <ais523> the URN would clearly be more useful if it referred to the file
04:41:25 <ais523> huh, something I learned today: the attacks on SHA-1 are still improving, Wikipedia says that with the latest techniques, a chosen-prefix collision on SHA-1 would cost about US$45000 of computer time
04:43:44 <shachaf> How much is that attacks getting better vs. GPUs or something getting better?
04:47:34 <ais523> most of it is attacks getting better
05:00:25 -!- tromp has joined.
05:04:34 -!- tromp has quit (Ping timeout: 246 seconds).
05:45:14 -!- ais523 has quit (Quit: quit).
05:54:33 -!- tromp has joined.
05:59:23 -!- tromp has quit (Ping timeout: 265 seconds).
06:48:45 -!- tromp has joined.
06:53:23 -!- tromp has quit (Ping timeout: 260 seconds).
06:56:27 -!- tromp has joined.
07:01:41 -!- int-e has quit (Remote host closed the connection).
07:02:37 -!- int-e has joined.
07:04:46 -!- lambdabot has quit (Remote host closed the connection).
07:07:35 -!- lambdabot has joined.
07:07:59 -!- imode has quit (Ping timeout: 260 seconds).
07:10:58 -!- Sgeo has quit (Read error: Connection reset by peer).
07:28:36 <fungot> int-e: they are trying to solve here? going to throw away
08:06:40 -!- user24 has joined.
08:07:57 <user24> Is anyone aware of a left-total esolang other than Zot? (All possible input strings are syntactically valid)
08:09:05 -!- hendursa1 has joined.
08:11:43 -!- hendursaga has quit (Ping timeout: 240 seconds).
08:37:34 <int-e> How about Malbolge
08:39:34 <esowiki> [[Special:Log/newusers]] create * Tuan2090 * New user account
08:47:51 <myname> well, if you count comments, most of them are?
08:48:05 <myname> like, bf ignores non-command chars in most implementations
08:57:03 <myname> you could argue wether or not a bf program with unbalanced brackets is syntacticaly valid
08:58:06 <user24> i'm thinking about all possible binary mappings. Iterate from 0 to limit, input the (n-ary) form of this number into the program and plot the relation between the inputs and the outputs somehow
08:59:00 <user24> *input into the program => use this as the program
08:59:52 <user24> somewhat unrelated: http://wry.me/hacking/Turing-Drawings
09:15:43 -!- sprocklem has quit (Ping timeout: 260 seconds).
09:16:04 -!- izabera has quit (K-Lined).
09:19:03 -!- izabera has joined.
09:23:43 -!- hendursa1 has quit (Ping timeout: 240 seconds).
09:25:17 -!- hendursa1 has joined.
09:33:45 -!- t20kdc has joined.
10:01:10 -!- Lord_of_Life_ has joined.
10:04:06 -!- Lord_of_Life has quit (Ping timeout: 246 seconds).
10:04:10 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
10:24:54 -!- ATMunn has quit (Quit: lol rip).
10:27:10 -!- user24 has quit (Quit: Leaving).
10:27:51 -!- ATMunn has joined.
10:38:51 -!- Lord_of_Life has quit (Read error: Connection reset by peer).
10:39:18 -!- Lord_of_Life has joined.
10:39:18 -!- Lord_of_Life has quit (Changing host).
10:39:18 -!- Lord_of_Life has joined.
11:04:17 -!- orbitaldecay has quit (Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in).
11:16:07 -!- tromp has quit (Remote host closed the connection).
11:20:12 <esowiki> [[Brainflub]] https://esolangs.org/w/index.php?diff=78090&oldid=78023 * Aryantech123 * (+190)
11:30:09 -!- iovoid has quit (Quit: iovoid has quit!).
11:32:51 -!- iovoid has joined.
11:52:11 -!- tromp has joined.
12:10:14 <esowiki> [[Conglument]] M https://esolangs.org/w/index.php?diff=78091&oldid=77224 * Hakerh400 * (+0)
12:29:56 <esowiki> [[Deklare]] M https://esolangs.org/w/index.php?diff=78092&oldid=75763 * PythonshellDebugwindow * (+3) /* The arithmetic system */ Correct documentation (equality -> assignment)
12:44:30 <fizzie> From elsewhere, but the animation's nice: https://twitter.com/AlanZucconi/status/1315967202797981696
12:48:31 -!- ski has quit (Ping timeout: 260 seconds).
12:50:28 -!- ski has joined.
13:01:42 -!- hendursa1 has quit (Quit: hendursa1).
13:01:59 -!- hendursaga has joined.
13:14:05 <esowiki> [[User:ThisIsTheFoxe]] https://esolangs.org/w/index.php?diff=78093&oldid=77895 * ThisIsTheFoxe * (+1512) added HTPL/HTPF section
13:55:28 -!- Sgeo has joined.
14:03:10 -!- Arcorann has quit (Read error: Connection reset by peer).
14:22:02 <b_jonas> ais523: I've been imagining something similar. suppose aliens start selling a magical box cheaply and in large numbers. this magical box has an ethernet connection, and you can do two things with it. either you upload a file, to which it gives you an unpredictable digest (which may be pure random, or a cryptographically good trap function with a key that we can't extract from the box and a seed that's
14:22:08 <b_jonas> new every time, there's no way to tell), or give the box a digest, and if anyone has got that digest from any box anywhere, it gives you the corresponding file.
14:23:34 <b_jonas> this would be the ultimate compression scheme, so suddenly most computers (including photo cameras and such) wouldn't need high capacity storage devices, or high bandwidth internet connections. some specialty high performance applications would still use traditional hard disks and SSDs, when the bandwidth and latency of the box is too small, or for old-style people like me who don't trust any new
14:24:17 <b_jonas> there might be a size limit for files you can upload, but it doesn't matter, you can always just upload it in chunks and upload a tree indexed by digests and transmit the digest of the root.
14:25:36 <b_jonas> physics probably bans this because of entropy stuff, but it at least still doesn't let you send signals faster than light speed, because the digests are long and random enough that you can't randomly guess the digest of any file someone else has uploaded without learning the digest indirectly from the box.
14:27:15 <b_jonas> this would let us simulate really large (but not necessarily extra-fast) hard disks that are easy to back up, because you'd only need to carry a digest to save the entire backup
14:27:52 <b_jonas> but it doesn't give you writable storage: if you want remote backups every day, you have to send a new digest to the remote location every day.
14:28:47 <b_jonas> also having a digest would essentially count as proof that you have the data that it points to, like for proving that you have gotten access to industrial secrets or copyright-protected information
14:29:20 <b_jonas> so you could have very short bits of information that you aren't allowed to distribute
14:30:32 <b_jonas> it would also help connect places where it's currently expensive to set up high bandwidth data connections for practical reasons, like in isolated places or between continents or to space
14:38:37 <b_jonas> also none of the properties would break if the digest was unseeded (so it gave the same result if two people upload the same data), and even computed by a known hash function that is cryptographically safe (eg. the aliens describe how to compute the hash function in the manual), but somehow I always imagine the digest as not reproducible, because that's somehow more believable
14:39:23 <b_jonas> you could even have it so that you don't need to upload anything to the box, as long as you have a file and compute its digest using the safe crypto hash function that the aliens specify in the manual, it's enough for anyone to download, which seems even more magical but doesn't seem to break anything
14:40:08 <esowiki> [[Works in progress]] https://esolangs.org/w/index.php?diff=78094&oldid=72175 * WhyNot? * (+15)
14:42:29 <b_jonas> but of course the digest has to be long enough to be secure from a birthday attack on an expensive fast parallelized GPU cluster
14:43:05 <b_jonas> even with any technology we or the aliens may have in the future
14:58:30 <b_jonas> mind you, if they work with a public hash function, but the boxes were so expensive we can't afford even a single one, yet we had access to a manual and knew that the boxes work, then we'd at least have a guaranteed crytographically secure hash function, which would be a nice consolation prize
14:58:47 <b_jonas> (until of course they destroy everyone with a death ray)
15:16:22 -!- t20kdc has quit (Ping timeout: 246 seconds).
15:19:19 <b_jonas> of course the device must be impossible to reverse-engineer, and if it communicates with other instances of the devices, then it has to do so such that we can't gain information from it, especially not about what files are uploaded or downloaded or their digests
15:19:33 <b_jonas> and it must be rectangular and painted black
15:21:15 -!- tromp has quit (Remote host closed the connection).
15:53:35 -!- tromp has joined.
15:58:22 -!- tromp has quit (Ping timeout: 246 seconds).
16:02:20 -!- tromp has joined.
16:03:58 -!- FreeFull has joined.
16:09:20 -!- xgqt has quit (Read error: Connection reset by peer).
16:13:34 -!- sebbu2 has joined.
16:16:22 -!- LKoen has joined.
16:16:25 -!- sebbu has quit (Ping timeout: 264 seconds).
16:24:22 -!- sebbu2 has changed nick to sebbu3.
16:24:34 -!- sebbu3 has changed nick to sebbu.
17:20:35 -!- t20kdc has joined.
18:10:29 -!- xgqt has joined.
19:00:50 -!- LKoen has quit (Remote host closed the connection).
19:37:56 -!- imode has joined.
20:35:16 -!- sprocklem has joined.
20:47:51 <esowiki> [[User:PythonshellDebugwindow]] M https://esolangs.org/w/index.php?diff=78095&oldid=78032 * PythonshellDebugwindow * (+45)
20:52:03 -!- user24 has joined.
21:18:09 <rain1> https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs
21:28:57 -!- t20kdc has quit (Remote host closed the connection).
21:30:10 <b_jonas> rain1: yeah, those are useful. the float to fix instructions on x86 suck really.
21:30:20 <b_jonas> it's useful not only for javascript.
21:30:51 <b_jonas> there are conversion instructions, but not ones that round to highest or lowest integer value on over/underflow, which is the behavior you often want
21:34:05 -!- deltaepsilon23 has joined.
21:34:32 -!- deltaepsilon23 has changed nick to delta23.
21:44:54 <zzo38> I thought make up a kind of compression for restaurant menu texts. It could be done using existing compression formats, with preset dictionaries and whatever, but also could be new ones; either way, would also be the base format which would pack the data to be optimized in the format.
21:50:38 -!- user24 has quit (Quit: Leaving).
22:04:37 -!- aaaaaa has joined.
22:05:12 <aaaaaa> Impact of order of files in tar archive on compressed size https://yurichev.com/news/20201021_tar_order/
22:09:20 <zzo38> I think 7-Zip normally uses solid compression separately per filename extension.
22:13:21 -!- FreeFull has quit (Read error: Connection reset by peer).
22:26:07 <b_jonas> zzo38: no, I think it just uses solid compression in blocks, and sorts files by default though you can override that, and the default sort order has changed "recently" (last ten years)
22:27:02 <b_jonas> zzo38: https://www.7-zip.org/faq.html
22:29:14 -!- FreeFull has joined.
22:29:45 <zzo38> O, OK, now I read that
22:32:24 <b_jonas> zzo38: and you can give the -mqs=off option to disable sorting if you specify an explicit list of files that you sort in some good way
22:34:43 -!- Arcorann has joined.
22:59:00 -!- FreeFull has quit.
23:11:05 -!- Arcorann has quit (Read error: Connection reset by peer).
23:11:34 -!- Arcorann has joined.
23:50:25 -!- LKoen has joined.
23:58:52 -!- esowiki has quit (Ping timeout: 260 seconds).