[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-saag
Subject:    Re: [saag] [kitten]  AD sponsoring draft-hansen-scram-sha256
From:       Tony Hansen <tony () att ! com>
Date:       2015-02-24 13:55:55
Message-ID: 54EC82EB.3040705 () att ! com
[Download RAW message or body]

On 2/18/15 7:57 AM, Sam Whited wrote:
> On Mon, Feb 16, 2015 at 6:21 AM, Dave Cridland <dave@cridland.net> wrote:
>> Worth asking in the XSF, there's likely to be implementation experience from
>> the Android client devs there.
> I wrote the SCRAM-SHA-1 implementation in Conversations. While I don't
> remember actual numbers off the top of my head, I can definitely tell
> you that there is a noticable delay with a 4096 iteration count
> (probably a little over half a second) on my HTC m7 (which is fairly
> beefy as far as phones go). HOWEVER—
>
>> However, clients need only do the iterations once, if the salt is stable, at
>> least in principle.
> —since we then store the session information in an LRU Cache in
> memory, it's only slow when you first login. I've thought about moving
> the session info to the database as well to make it even more
> persistant, but decided it wasn't enough of a problem to bother
> polluting the database.

We have implementations of both SCRAM-SHA-1 and SCRAM-SHA-256 on 
multiple phone platforms, both Android and iOS. Yes, it can be rather 
slow. But, as Sam says above, caching does mitigate the issue for 
subsequent uses.

This is why I pushed back when it was suggested before in KITTEN to 
raise the number higher than 4096.

     Tony Hansen

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

[prev in list] [next in list] [prev in thread] [next in thread]