I'm going to attempt to summarize/rehash the comments I've found have a
significant relevance to the quality of the algorithm. I've had a lot of great
feedback, which I'm tremendously thankful for. My apologies in advance for any
important aspects that any of you have highlighted if I forget t
On 05/30/2012 03:25 PM, Maarten Billemont wrote:
I'm currently considering asking the user for their full name and
using that as a salt in the scrypt operation. Full names are often
lengthy and there's a good deal of them. Do you recon this might
introduce enough entropy
In the case of salts
On Wed, 30 May 2012, Maarten Billemont wrote:
> I'm currently considering asking the user for their full name and
> using that as a salt in the scrypt operation. [[...]]
Digressing slightly from crypto, note that "full name" is not as tidy
or troublefree a concept as one might think. It's instru
On 30 May 2012 13:25, Maarten Billemont wrote:
> On 30 May 2012, at 22:17, Marsh Ray wrote:
>> On 05/30/2012 02:59 PM, Nico Williams wrote:
>>>
>>> This is why salting is important. They should not be able to build
>>> a single rainbow table that works for all cases.
>>
>> In order to be useful,
On Wed, May 30, 2012 at 3:25 PM, Maarten Billemont wrote:
> I'm currently considering asking the user for their full name and using that
> as a salt in the scrypt operation. Full names are often lengthy and there's
> a good deal of them. Do you recon this might introduce enough entropy or
> s
On 30 May 2012, at 22:17, Marsh Ray wrote:
> On 05/30/2012 02:59 PM, Nico Williams wrote:
>>
>> This is why salting is important. They should not be able to build
>> a single rainbow table that works for all cases.
>
> In order to be useful, the salt has to be large enough to not have large
> n
On 05/30/2012 02:59 PM, Nico Williams wrote:
This is why salting is important. They should not be able to build
a single rainbow table that works for all cases.
In order to be useful, the salt has to be large enough to not have large
numbers of collisions across large user populations. Ideal
On Wed, May 30, 2012 at 2:32 AM, Jon Callas wrote:
> (1) You take the master password and run it through a 512-bit hash function,
> producing master binary secret.
>
> You pick scrypt for your hash function, because you think burning time and
> space adds to security. I do not. This is a place w
Peter commented:
#That users know passwords and they "work" is a large part of the problem
#with passwords: the same low entropy security token is used for multiple
#systems with varying levels of sensitivity. When using passwords, both the
#user and the end systems must, in general, be trusted w
On 05/30/2012 04:06 AM, Maarten Billemont wrote:
First of all, thanks for your time and very valuable feedback.
On 30 May 2012, at 07:20, Marsh Ray wrote:
On 05/29/2012 06:01 PM, Maarten Billemont wrote:
Initially, my recommendation for a master password was to use a
sufficiently-random 12-c
On 30 May 2012, at 15:43, Douglas Huff wrote:
> Not to mention that adding that functionality almost forces the real seed to
> come from a prf/prng meaning using scrypt for the initial key deriv starts
> making sense as you're now deriving a key for a cipher which is what scrypt
> is for.
I'm u
What about including a random salt when generating the key from the master
password? The application could either generate the salt for you on first use
(and recommend writing it down and keeping in a safe place) or allow entering
an existing salt (e.g. when transferring to a new device).
That
On Wed, May 30, 2012 at 9:57 AM, Steven Bellovin wrote:
>
> On May 29, 2012, at 7:01 22PM, Maarten Billemont wrote:
>
>> Dear readers,
>>
>> I've written an iOS / Mac application whose goal it is to produce passwords
>> for any purpose. I was really hoping for the opportunity to receive some
>>
On 30 May 2012, at 16:26, Wyss, Felix wrote:
> What about including a random salt when generating the key from the master
> password? The application could either generate the salt for you on first
> use (and recommend writing it down and keeping in a safe place) or allow
> entering an existing
On May 29, 2012, at 7:01 22PM, Maarten Billemont wrote:
> Dear readers,
>
> I've written an iOS / Mac application whose goal it is to produce passwords
> for any purpose. I was really hoping for the opportunity to receive some
> critical feedback or review of the algorithm used[1].
>
> --
>
On 30 May 2012, at 15:09, Jonathan Thornburg wrote:
> You're right, sharing of master passwords is a bad idea. But given
> human nature, it happens, and a security system needs to take that
> into account. There are also a lot of other ways a master password
> can be compromised and thus need rol
You're right, sharing of master passwords is a bad idea. But given
human nature, it happens, and a security system needs to take that
into account. There are also a lot of other ways a master password
can be compromised and thus need rolling over, e.g. shoulder-surfing,
virus keyloggers, theft of
Thanks a lot, Jon, for taking the time and sharing your thoughts.
On 30 May 2012, at 09:32, Jon Callas wrote:
> Your algorithm is basically okay, but there are a couple of errors you've
> made, things you and I will disagree over, and one flaw that I consider to
> wreck the whole thing. But all
Which is not to say that I find the single case, or cryptographic
"strength" to be superior to other systems. But it certainly
complicates the job of an attacker seeking to exploit large numbers of
passwords, or cross-service password reuse. Imperfect, but not a
terrible step.
On Wed, May 30, 2012
I would hazard a guess that this system would stand up well against
mass attacks, at the very least making them much less economically
desirable or feasible for attackers who benefit most from password
dumps. Most architectures fail in single cases, anyway, due to poor
user awareness, poor user dec
First of all, thanks for your time and very valuable feedback.
On 30 May 2012, at 07:20, Marsh Ray wrote:
> On 05/29/2012 06:01 PM, Maarten Billemont wrote:
>> Dear readers,
>>
>> I've written an iOS / Mac application whose goal it is to produce
>> passwords for any purpose. I was really hoping
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Your algorithm is basically okay, but there are a couple of errors you've made,
things you and I will disagree over, and one flaw that I consider to wreck the
whole thing. But all of the problems are correctable, easily. If I have not
understood som
On 30 May 2012, at 02:49, Jonathan Thornburg wrote:
> On Wed, 30 May 2012, Maarten Billemont wrote:
>> Master Password is different in that it generates passwords based
>> purely off of a user's master password and the name of the site.
>
> Is there a provision to rollover the master password
>
23 matches
Mail list logo
