jdev - 2023-05-22

Hi. Is there any file exchange ways/protocols that use encrypted channels, such as PGP?

Hello H3rnand3zzz. The currently common HTTP upload method should work just fine with PGP, same way it does with OMEMO.

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

Omemo is great. But is there something for PGP?

Nothing about it should be specific to OMEMO

But the title is "XEP-0454: OMEMO Media sharing" ✏

The method itself has nothing to do with OMEMO, but of course you must respect the title. :)

Mostly it's done that way because of the old version of OMEMO that is used, that can only transport plain text messages.

No idea what is the state of methods involving full stanza encryption

But if I want to implement some kind of PGP transfer algorithm, how can I do it according to standard? Would it require developing of the proposal?

Full stanza encryption would probably require server-side support

No

What would be the most appropriate way to send PGP-encrypted file over XMPP protocol? Ideally, the recipient's client should automatically decrypt the file.

H3rnand3zzz: Conversations just http uploads .pgp files

Peter Waher, seems your client which is unknown to me uses sha-256 as hash algo for entity caps

are you the developer of this client?

yes

any particular reason why you decided on sha-256, when its not mandatory for any client to implement?

It is not prohibited, so we chose to use something else than sha-1 (which we consider should be phased out everywhere, if possible, as should md-algorithms). We interpret “MUST implement” in XEP-0115 to mean must support (as recipient of information), not MUST be used when publishing your hash (i.e. the words “An implementation MAY support other algorithms”). Clients should be encouraged to support more modern algorithms in our eyes.

0390 says for sha256

Or we dont follow that?

Mildly interested in whats the current thing here too

Peter Waher, I would recommend you to go for it in XEP-0390 (or use an even better algorithm, for instance the faster blake3), but play safe with compatibility in XEP-0115 support.

strictly speaking, https://xmpp.org/extensions/xep-0414.html is the reference for which hash functions to use within XMPP

Thanks 👍

(and XEP-0300 has a common wire format for transporting hashes and announcing support for hashes, fwiw)

XEP-0414 states SHA-1 SHOULD NOT be used, and SHA-256 MUST be supported… But XEP-0414 is also deferred, so I don’t know how much weight it has…

jonas’, oh, XEP-0414 still hasn’t been updated for blake3.

Ah yeah 115 says only sha 1

Peter Waher, deferred is a lie, it's just that the spec is experimental :)

Which granted thats why 390 exists ✏

Peter Waher, you are right that you are allowed to use anything you want when publishing, its just a weird decision for a protocol extension that is aimed at communicating capabilities to *other* clients, personally i would have chosen something that secures that as many clients as possible can deal with it. Especially as there is no gain in using something like sha256.

Yeah deffered means basically ask to implement imo

lovetox, "other clients" can include yourself too

Link Mauve, as they say, patches welcome

Sure, will do, I’m just writing other patches for other projects atm.

MSavoritias (fae,ve), no, 390 exists because of collision attacks inherent to '115, the lack of hash agility could've been addressed in a much more simple manner

Anyway: What algorithm you support shouldn’t really matter. I guess other clients just match (algorhm, hash) as string comparisons, to be one the safe side (i.e. support new algorithms as they arise), and do not try to decode or regenerate the digests.

(before they decide to do a service discovery on an entity)

> MSavoritias (fae,ve), no, 390 exists because of collision attacks inherent to '115, the lack of hash agility could've been addressed in a much more simple manner Ah i thought it was the has agility ↺

Noted

What's the thing about 300 and 414, is one redundant?

(the agility was part of it, granted, looking back at the motivation section)

pep., no, one is wire format, one is recommendations for which things to actually use

Or one updating the other?

Ok

pep., they were split from one another so that 300 could advance to Standards Track Stable, while 414 could become Informational Active

Ok cool 300 references 414

(and all things can just refer to '414 for hash function recommendations even if they don't or cannot use the '300 wire format for whatever reason)

Peter Waher, if a specification hardcodes a single hash in its examples, you can be sure many implementations will only ever support that one hash mechanism.

You cannot consider all possible ways developers create bugs on the other hand…

This one is a constant.

where is it defined as a constant?

im not sure what you mean by > and do not try to decode or regenerate the digests. I only accept a hash into the cache if i verified that it was correctly computed, and thats why i need to compute it myself from the disco info, this means it depends on the language and ecosystem what hash algos are easily available ✏

Peter Waher, in human developers I guess.

> These recommendations ought to be reviewed yearly by the XMPP Council

https://burtrum.org/up/0e49768e-8b47-4c78-bf16-cebbd9b2c0d6/2zo1ki.jpg

moparisthebest, it's not active yet!

What are you all waiting for! go make it active :P

> i verified that it was correctly computed You cannot determine if it is correctly computed, unless you have the discovery information already (which you try to avoid to get). You can check if it has the correct length, but that would require you to recognize the algorithm used. But remember: The digest is not used to protect the information, just avoid performing a service discovery, similar to ETAG in HTTP, meaning, you perform the service discovery if you don’t recognize the digest from earlier. If it is “correct” or not, is really meaningless, from the receiving end. The point is to perform a new service discovery, only if the digest changes.

Peter Waher, that is one way to use it, but I don't know of any client which implements it that way.

(Also, if a client computes it “incorrectly”, but “consistently”, this method would still work.)

The implementations I know have two maps: `jid -> digest` and `digest -> disco#info`. And they only accept entries in the second map after verifying that the digest matches the disco#info.

(and they may persist the second map to disk, even)

If you perform a validation of the digest as you say, you should support modern algorithms, btw.

not for '115

where the sha1 is the least of your problems, really

anyway, let me know if I do anything incorrectly, that breaks any of the specifications. As I understand it, the use of SHA-256 does not break the specifications. Thanks for the input, good to know how others use the attribute.

Peter Waher, if you dont verify that the hash was computed correctly it would be trivial to poisen your cache

lovetox: Not if the cache was implemented as a cache (i.e. limiting number of digests / JID), as a cache should.

Only if you share the cache across clients

It is allowed to change hash often

moparisthebest, across remote JIDs even

Yes sorry that's what I meant

Hm maybe i understand this wrong, you cache a hash per jid? would that make the cache less efficient?

Also: You can only introduce new hash values from a JID, if you have access to that account. So a malicious actor injecting hash digests for a JID would have access to the credentials of those accounts. In such cases there are bigger problems.

A client can change supported features often, and thus their digests

If your cache is implemented to remember all digests over time, it will grow obviously

i dont see how changing your hash because you change caps is of any relevance to the discussion

Needlessly, btw

so did i understand you correctly you save a hash per jid?

no

I do not save hashes per jid

my caches work differently

And include time and space considerations

Unused elements are purged

so if you query my disco info and i answer with almost no caps, but include the hash of your client, how will your client react to if it receives that hash from another user of your client?

I don’t query disco, I receive presence with hash. If hash is not recognized from sender, I perform discovery. I consider every sender as its own universe, and do not assume digests mean the same thing from different senders, for the reasons mentioned above. I treat it as an ETAG basically.

sound to me like you store hash per sender

That's the only secure way to do it if you don't validate

of course, and it makes caching less efficient

But it's a nice way to support new-shiny-hash-algorithm without even knowing it exists

because it means you will query each and every member of a 1000 member room, even if they all have the same client with the same caps

Trade-offs all the way down

You could do a combo

Validated shared cache for algorithms you understand, per jid for those you don't

Good idea.

i mean all this means nothing if you dont support any p2p stuff anyway

nobody uses disco info for anything serious other than jingle

we definitely use it for other things than jingle

for example?

IoT and E2EE, just to mention two

oh, and social networking capabilities, digital identities, smart contracts, tokenization and monetization.

and all these things dont need to work if someone is offline? Because then the disco info query will not work

Even jingle shouldn't really use caps right? If I log into a client that doesn't support calls I still want to see my missed calls when my other clients come back online

yes i think this was solved for jingle calls

they send now some message which is stored in MAM

dont know if this is available for filetransfer as well

Yea kind of makes sense for jingle file transfer though

but yeah, ... seems you dont even need disco info for that

now its just for "which client does this user use"

its kind of important for services though, server, MUC etc

BTW: If you share hashes between clients, as mentioned above (in the MUC case), you actually have the possibility to inject/poison caches (if using SHA-1): Consider a malicious user knowing about a new set of disco info, before others on a server (perhaps taking it from another server, or guessing it). It calculates the hash, reports it to a new server (or many servers) who then perform service discovery, where the malicious user responds with some fake service discovery (which results in the same digest, as is possible now it seems, with SHA-1). As the server takes this as the defacto-response, it will not ask again, when other non-malicious users ask, and services will stop working on the new server, if service discovery is an intrinsical part of the operation. Not sure why anyone would do this, but there always seems to be one… ✏

I didn't think generating sha1 collisions was cheap enough to worry about that yet

surely it will get cheaper

I mean, git is a way juicier target if so

yes

We shouldn't worry about XMPP until high profile git repos start getting attacked :)

but attackers attack what they can get away with

also, there's state-sponsored "hacking" ✏

I agree it's just going to get cheaper/easier though

lot of work/money to poisen a single hash, of course could happen

Peter Waher, XEP-0115 makes it much easier to generate collisions than breaking SHA-1, see http://web.archive.org/web/20230118035239/https://mail.jabber.org/pipermail/security/2009-July/000812.html

Much easier.

and with again almost no gain, as said almost nobody uses disco info for anything serious

Does anyone know why the XEP says > Because of how the hash output is used in entity capabilities, the protocol will not be subject to collision attacks even if the hash function used is found to be vulnerable to collision attacks.

great, Link Mauve, so basically to be save against collisions the sha algo does not matter and we would need to cache per jid

Correct.

no, we need ecaps2

Or indeed, XEP-0390.

It is allowed to note multiple vulnerabilities (plural), and not only consider the most severe vulnerability, one at a time, of course. Especially if discussing implementation.

it was a side note, btw

lovetox, regarding the statement in the xep: that is a good question

that sentence was added with https://github.com/xsf/xeps/commit/df683bc14448c51796d2bd4c657ad5fab38b01c0#diff-7317d93667443a69e313bdffd7125c1213ad5d6b38c8a2bdf26237fa902737e7R449

so maybe ask psa