zeen

-- this module is global
module.host = "*";

-- list of hosts on which to add the component
local hosts = {
	["example.com"] = true;
	["myhost.com"] = true;
};

-- the jid of the component

zeen

meta = {
	display = "Name visible in UIs";
	name = "name_in_code";
	type = "object";
	properties = {
		{
			display = "Call my function";
			name = "myFunc";
			type = "function";
			parameters = {

zeen

<iq from="conference.jabber.org" to="[email protected]/resource" id="x" type="result">
  <query xmlns="jabber:iq:register">
    <registered />
    <instructions>You need an x:data capable client to register nickname</instructions>
    <x xmlns="jabber:x:data">
      <title>Nickname Registration at conference.jabber.org</title>
      <instructions>Enter nickname you want to register</instructions>
      <field type="text-single" label="Nickname" var="nick">
        <value>waqas</value>
      </field>

zeen

Peter asked me to post a summary of the pre-image attacks I found and the discussion which followed, so here it is.

== Introduction ==

On reading XEP-0115: Entity Capabilities, I discovered that it is trivially easy to do a preimage attack. That is, given a service discovery response, it is trivially easy to create a different service discovery response which has the same verification string. This can obviously be used to poison caps caches, effectively eliminating any security advantage of using hashes.

=== Attack 1 ===

<identity category='client' type='pc' name='SomeClient'/> <feature var='http://jabber.org/protocol/muc'/>