<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 8, 2017, at 8:22 AM, Robin Wood <<a href="mailto:robin@digininja.org">robin@digininja.org</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div>We talked about storage of the encryption key and they basically said that is out of scope, don't worry about it.</div></div></div></blockquote><div><br></div><div>Hoo boy. Then it doesn’t much matter what you tell them because, as Ray Dillinger already pointed out, this is the limiting factor.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div>Talking to a friend who knows crypto, he says that the encryption should not have a negative interaction with the bcrypt hash and so adding it will slow down the process of recovering a PIN.</div></div></div></blockquote><div><br></div><div>Not if your adversary steals the encryption key along with the hashed PINs. </div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div>[2] 10 sec per hash works out at just over a day to brute force a 4 digit PIN if I've done my maths right.</div></div></div></blockquote><div><br></div><div>That’s about right, but earlier you wrote:</div><div><br></div><div><blockquote type="cite"><span style="color: rgb(33, 33, 33); font-size: 13px;">The encryption is fast enough to not affect login times </span></blockquote><br></div><div>That made it sound like latency matters. 10 seconds is a pretty long time to make a user wait.</div><div><br></div><div>rg</div><div><br></div></div></body></html>