jdev - 2025-10-05

lovetox, which client did that? I guess this is in relation to my "unnamed-chat" merge request, right?

i think conversations

yeah, C-family clients do this at least for MUCs configured as private invite-only

I forget if they also do for intended public MUCs

They display it? Or they actually *configure* it?

either they set the bug mark or configure it on the muc

but that i was confronted with this was probably years ago

hence my question if someone still does this

hmm other question if there is a file hash like in https://xmpp.org/extensions/xep-0447.html

is this the hash of the encrypted file (if we encrypt with aes for omemo) or the unencrypted?

i can see arguments for both ..

hmm but i guess it should be the unencrypted, because thats how it ends up on the harddrive in the end

gotta be the hash of the file actually shared, so after encryption in that case

why?

Because that's the file shared

Plus leaking the hash of the unencrypted file sounds dangerous

so the only purpose of this hash is to check if the file transfer was complete?

and/or not have to re-download if you already have it

but thats not possible then or?

the hash of a encrypted file is on every filetransfer different

so you can never check

it can be, or the same encrypted file could be shared right?

sounds unrealistic

why would someone keep an encrypted file on harddisk to reshare it

Could share using same url

this is not a question of if it would be possible to share the same encrypted file multiple times

the problem is, this definitly a edge case that you would see the same encrypted file twice

I don't know why it would be

because i dont know any client that can do this?

it doesn't really matter though, the hash can't be of the file before encryption because that wouldn't work and more importantly wouldn't be safe

because my implementation could also not do this

clients aren't the whole world

yeah and nobody talked about the world, except you just now

you said you didn't know any clients that did this /shrug

but anyway .. if its the one after encryption then its much less useful .. need to think if i even store it then

'447 can't even be used with encryption can it

yes if i say something is an "edge case" meaning it does not happen a lot, and you say the opposite, then i would assume you have excamples how and where this often happens ✏

By that definition all of '447 is an edge case cause nothing uses it lol

there are already multiple clients using, dino, kaidan e.g.

and also the hash is not only in 447

its also in SIMS which cheogram uses

btw, 447 can be used with encryption, you just need omemo2

kaidan can because it's the only client that does SCE right?

447 could also be used when you dont include metadata about the file or?

all metadata attributes are optional

ah no

im an idiot, yes you need full stanza

key is in the link

dino uses it probably only unencrypted

as will gajim for now

so if the hash is encrypted such that the server can't see it it would be safe to send the hash of the unencrypted file 🤔

> essential as they provide end-to-end file integrity and allow efficient caching and flexible retrieval methods.

so if caching is the described use case i need to store the hash

and because gajim does not yet support full stanza i delay the decision what to do about encrypted files

maybe i send a mail to the list

The hash is of the original file content (unencrypted). Revealing a hash value tells you nothing about the file or its contents, unless: you already have the file to match its hash value, or a weak hashing method is used that allows a reversal (which, even then, doesn't uniquely give the original data for files of any reasonable size)

its not revealed anyway, because the stanza is encrypted. But its undefined as i see it

I don't see how hashing "before encryption" would make any sense. it should be a hash of the file being transferred. the encrypted file is the file being transferred. from the pov of SIMS/SFS the unencrypted file doesn't exist

it definitly does not exist for these XEPs or they would have included text about it

but only because the authors didnt think of something, means not we can do it not now

it would be a layer violation to do it that way anyway

That's a question of whether you're putting encryption above or below SFS. SFS doesn't consider encryption because it's a separate layer.

exactly, i place it above SFS

we create a SFS stanza, afterwards we encrypt it

Right, so the hash value is before any encryption is applied

for the stanza encryption sure. but you have to encrypt the file first before you get to the SIMS/SMS/OOB/HTTP upload

but thats not a layer violation as i see it

if SFS is about unencrypted files, i put data in it about unencrypted files ✏

All of the metadata is for the unencrypted file (because it's meaningless for an encrypted file)

yeah but anyway, nobody can be right or wrong about this, its defintily something that was not thought about

and its not a clear cut case

> All of the metadata is for the unencrypted file (because it's meaningless for an encrypted file) this makes no sense. there is no unencrypted file ↺

the file that is to be uploaded/transferred may be encrypted or not using any mechanism or not which the transfer layer has no knowledge of

i mean we can add omemo specific elements into SFS, so SFS knows about the encryption

would make it probably a bit cleaner

but not much different for the clients who receive the file, they know anyway

sure. you could do that. that feels like a very different sort of thing and I think it's a bad idea, but it's definitely not how it is now

well, not omemo specific since you can't encrypt files with omemo. but yes I get your meaning

https://xmpp.org/extensions/xep-0396.html

its also not defined there

> The hash elements provide end-to-end file integrity and allow efficient caching and flexible retrieval methods. End-to-end means you only have the original data at either end, i.e. it's the original unencrypted data. Efficient caching doesn't work well for encrypted data.

> https://xmpp.org/extensions/xep-0396.html this is transport encryption so I guess in this case there is no encrypted file at all ↺

so .. the hash would be of the unencrypted file

in that case yes. since that's all that exists

you just need to see the upload as transport encryption :)

but yeah i agree, its ugly ..

I mean the whole "encrypted file" concept was suppose to be a temporary hack. But temporary solutions have a way of sticking around ;)

how would you solve it differently with http?

Whether you upload an encrypted version of the file, or send it over an encrypted stream, that's all just a transport method; SFS is concerned with the original file.

i mean if you design it not as a hack

if we had a way to transport encrypted with http upload I'd agree I think

singpolyma, for me its clear that the hash of the unencrypted file, benefits clients more. So how would you suggest to get there?

staying on a point, just out of principle is not a good solution

let me read the aesgcm xep again

yeah i mean putting the fragment in the link etc is not pretty, lets imagine we would create a XEP who fixes that, then we would probably add a <encrypted> element or something to the stanza, and would transport the key there

but it would be reeeeaallly weird if we put then the unencrypted hash into the <encrypted> element as metadata :D

at this point you would say, put the encrypted hash in the <encrypted> element, and SFS has the unencrypted ✏

the trick is that you only need the key for some of the transports in a multi-transport case. Like if I had Jingle FT and HTTP upload both I could have security on the jingle case using another mechanism and not need a key in the file transfer for that

so instead of <url>...</url><key>...</key> you need more like <url key="...">...</url> which is basically what we get now with aesgcm://

so maybe if you squint you could consider xep0454 a transport mechanism and then theTedd would be right, hmm. It's not really written that way and I don't think anyone implements it that way, but it sort of is one

so maybe we could reword 0454 to be more clear about this, that this is a weird transport mechanism and the file being transferred is still the "unencrypted" file even if http upload layer deals exclusively with the encrypted file

yeah i think, we have a encryption layer, its not pretty and clear shown in the stanzas and xml, but it is effectivly a layer, and we should not leak this encryption data into SFS only because we have no pretty layer

> The hash is of the original file content (unencrypted). Revealing a hash value tells you nothing about the file or its contents, unless: you already have the file to match its hash value, or a weak hashing method is used that allows a reversal (which, even then, doesn't uniquely give the original data for files of any reasonable size) it reveals at least what you said, and at least one other I can think of: 1. The hash is known - some-pirated-movie.mp4 or snowden-leak.txt or whatever 2. If the same file is uploaded multiple times by the same or different people, these encrypted versions are different but the hash reveals they are the same file those alone are enough to never do it, and there are probably more ↺