[Security] Trivial preimage attack against the entity capabilities protocol

Jiří Zárevúcky zarevucky.jiri at gmail.com
Wed Jul 22 08:53:39 CDT 2009


2009/7/22 Waqas Hussain <waqas20 at gmail.com>:
> Peter asked me to post a summary of the pre-image attacks I found and the
> discussion which followed, so here it is.
> [...]

Nice analysis. :)

> === Attempting to create a new algorithm ===
> Peter suggested that the new algorithm may be based on just feature names.
> Dave Cridland suggested using NUL as the delimiter, which is illegal in XML
> and UTF-8.

Sounds like a good idea to me.

> This needs some thought though. Does it never make sense for a presentity to
> notify its subscribers about changes to its identities or service discovery
> extensions?

I thought the purpose of entity capabilities was not only notifying of
changes, but also eliminating the need to request it at all.

If the new algorithm doesn't include all the information present, then
it's quite useless in this regard and we're back to flooding our
entire rosters with disco requests on login. Don't forget that
entity's identity may be important for the client to decide how to
present it or work with it.

> There was consensus about killing off XEP-0128 (Service
> Discovery Extensions), with comments like 'cast out', 'inherently evil',
> 'more evilness lurking there' and 'It's just wrong'. I quoted those because
> I happen to agree. This probably deserves a separate thread.

I tend to agree as well.

> === A new XEP and namespace? ===
> Dave suggested "We can just use a new hash algorithm name, that should
> surely have a similar end-result, but be treated as an unknown hash by
> existing XEP-0115 implementations."
> Personally I would prefer a clean new XEP. We already have a Legacy Format
> (possibly in wider use than the current format). Updating XEP-0115 may lead
> to having Legacy and Legacy-Legacy formats. But I'm not particularly opposed
> to it either.
> --
> Waqas Hussain
>

I'd definitely prefer a new XEP.


More information about the Security mailing list