Subject: Re: [xmpp] SCRAM example

From: Jehan Pagès <[email-masked]>
Date: Thu, 10 Mar 2011 02:04:57 +0900

Hi all,

On Thu, Jun 24, 2010 at 1:22 PM, Peter Saint-Andre <[email-masked]> wrote:
> On 6/21/10 4:06 PM, Peter Saint-Andre wrote:
>> On 6/21/10 3:54 PM, Waqas Hussain wrote:
>>> On Tue, Jun 15, 2010 at 1:31 AM, Peter Saint-Andre <[email-masked]> wrote:
>>>> Would someone like to write up the protocol flow for a SCRAM example?
>>>> That might be more useful than the PLAIN example.
>>>>
>>>> /psa
>>>
>>> The following is the log of a SCRAM negotiation between Prosody and
>>> Pandion ([email-masked], with password r0m30myr0m30), copied
>>> from Pandion's XML console. Also included is the decoded base64 data.
>>
>> Thanks, Waqas, that's just what I was looking for!
>
> This has been incorporated. Thanks again.

The example is nice, but it would have been nicer to write down the
password as well! As I wanted to test a personal implementation (in
Objective Caml, which I just finished!) against this same example, I
had to dig out the email (fortunately I remembered this example was
coming from an email from the ietf mailing list) to be able to do so!
Right now without writing the password down in clear in the RFC, the
example is only "half-useful".

Also the step 11 in the example says:
«
The decoded base 64 data is "c=biws, r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0
   AAe124695b-69a9-4de6-9c30-b51b3808c59e, p=UA57tM/
   SvpATBkH2FXs0WDXvJYw=" (line breaks not included in actual data).
»

while it should be:
«
The decoded base 64 data is "c=biws,r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0
   AAe124695b-69a9-4de6-9c30-b51b3808c59e,p=UA57tM/
   SvpATBkH2FXs0WDXvJYw=" (line breaks not included in actual data).
»

-> there is no spaces before "r=" and "p=".

And finally I have a question for people having implemented SCRAM.
Does it take like very long to compute? For me it does (though it is
still a very early implementation). That's the Hi loop in particular
(in this example 4096 loops with a HMAC and a XOR at each step).

I know that's only made to be computed once, but... still...

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Mar 2011 10:16:06 -0700

> example is only "half-useful".

True. I assume you're referring to:

http://www.ietf.org/mail-archive/web/xmpp/current/msg01000.html

> -> there is no spaces before "r=" and "p=".

Correct.

I can fix both of these issues during "AUTH48":

http://www.rfc-editor.org/pubprocess.html#auth48

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Waqas Hussain <[email-masked]>
Date: Thu, 10 Mar 2011 12:37:56 +0500

> I know that's only made to be computed once, but... still...

It's slow, and that's by design, to make brute force attacks harder.

The last benchmark figure I remember is for a pure Lua interpreted
version, and that was around 10 Hi per second. Interestingly, in that
version, the XOR operation took significant time, because of Lua's
lack of bit-ops, and me emulating them via arithmetic.

--
Waqas Hussain

---

From: Jehan Pagès <[email-masked]>
Date: Sat, 12 Mar 2011 22:12:17 +0900

Hi,

> http://www.ietf.org/mail-archive/web/xmpp/current/msg01000.html

Right.

> http://www.rfc-editor.org/pubprocess.html#auth48

Nice. :-)

Jehan

---

From: Jehan Pagès <[email-masked]>
Date: Sat, 12 Mar 2011 22:48:08 +0900

Hi,

> It's slow, and that's by design, to make brute force attacks harder.

I see. Obviously it should be.

> lack of bit-ops, and me emulating them via arithmetic.

When you say 10 Hi, you mean 10 iterations of the Hi?! (which would be
extra slow, especially if we consider the RFC example with 4096
iterations! So the computation would take around 400 seconds ~ 6/7
minutes!)

Or do you mean 10 full Hi computations (then I would say that's pretty
fast, especially because that's an interpreted language and it has no
bitwise operation apparently as you say)? If this latter is the case,
do you remember the size of the data, of the salt and the iteration
count which were used for this benchmark (because obviously if you
iterate 100 times and 4096, that's not the same)? I tried to make some
search on the web if there was any page about this benchmark (probably
for Prosody? I see it uses Lua, but I could see no benchmark on their
blog nor the blog of the person who implemented SCRAM on Prosody).

Thanks!

Jehan

---

From: Jehan Pagès <[email-masked]>
Date: Sat, 12 Mar 2011 22:52:41 +0900

Hi again!

> blog nor the blog of the person who implemented SCRAM on Prosody).

And obviously knowing the hash (Sha1? MD5?) they used would help also!
Some hash algorithms are much faster than others (especially when you
run them thousands of times!).

Thank you for any information! :-)

Jehan

---

From: Remko Tronçon <[email-masked]>
Date: Sat, 12 Mar 2011 15:17:00 +0100

Hi Jehan,

> bitwise operation apparently as you say)?

Lua compiles to bytecode, which means it's not necessarily slow (also,
Lua is known to be quite fast). Prosody uses SHA-1 hashes (and IIRC,
4096 iterations).

To compare: Swiften's C++ implementation does about 74 Hi (4096
iterations, 16 byte password, 16 byte salt) per second. We don't do
any special tricks or optimizations; I seem to recall SHA1 was the
bottleneck (our SHA1 is not very optimized, just standard public
domain C version). If C++ does 74Hi, then 10 Hi in Lua sounds very
plausible.

cheers,
Remko

---

From: Jehan Pagès <[email-masked]>
Date: Sun, 13 Mar 2011 21:06:07 +0900

Hi,

> domain C version). If C++ does 74Hi, then 10 Hi in Lua sounds very

I see. Thanks for the information.

My implementation is not the most performant right now but it is also
I who implemented HMAC and SHA1. I'll improve it with time.

Also it is hard for me to do real benchmark as my machine is actually
a small netbook (you know, the 10 inches screen-kind, less than 300
dollars where I cannot even watch high quality videos, unless I want
to feel like I watch a stroboscope)... So I cannot really compare my
tests with yours... :-/

Thanks :-)

Jehan