On 2016-08-17 22:48, Charles R. Portwood II wrote:
On Sat, Aug 6, 2016 at 12:55 PM, Charles R. Portwood II
wrote:
memory_cost = 1 MiB
time_cost = 2
threads = 2
I'd like to gather some last feedback and make sure there aren't any
serious objections to these cost factors (or anything else for
On 8/17/16, 3:48 PM, "Charles R. Portwood II"
wrote:
>Hi everyone,
>
>I've spent the last week and a half playing around with various cost
>factors on different virtual machines and hardware (including compiling
>this down for armv6 and testing on a Pi Zero), and looking over the spec
>a bit more
On Sat, Aug 6, 2016 at 12:55 PM, Charles R. Portwood II <
charlesportwoo...@erianna.com> wrote:
>
>
> I think there's a bunch of ways we can tweak this. As there's no "bad"
> values for any of these cost factors per the spec, it may just be easy to
> set the costs even lower end user decide if they
On 8/6/16, 1:55 PM, "Charles R. Portwood II"
wrote:
>Typically a run time of of under 50 ms is the target goal. Argon2 can be
>tweaked to use a specific amount of memory, time, or CPU cores. Trying to
>find good default cost factors is problematic since all 3 of those
>factors are variable on any
On Sat, Aug 6, 2016 at 11:37 AM, Lauri Kenttä
wrote:
> On 2016-08-06 17:47, Charles R. Portwood II wrote:
>
>> Absolutely. What are your thoughts on the following cost factors?
>>
>> time_cost = 3
>> memory_cost = 12
>> threads = 1
>>
>> The reference library provides a CLI program where these va
On 8/5/16, 2:20 PM, "Charles R. Portwood II"
wrote:
>It breaks the API in the interim between this RFC and a potential future
>one. The $options parameter for both password_hash and
>password_needs_rehash is optional. Making it required for one algorithm
>but not another changes the API's for bot
On 2016-08-06 17:47, Charles R. Portwood II wrote:
Absolutely. What are your thoughts on the following cost factors?
time_cost = 3
memory_cost = 12
threads = 1
The reference library provides a CLI program where these values are
listed. A memory_cost factor of 12 would be 4 MiB.
Looks like the
On Sat, Aug 6, 2016 at 6:09 AM, Niklas Keller wrote:
> 2016-08-05 22:51 GMT+02:00 Lauri Kenttä :
>
>> On 2016-08-05 21:20, Charles R. Portwood II wrote:
>>
>>> On Fri, Aug 5, 2016 at 12:12 PM, Tom Worster wrote:
>>>
I can understand an argument that it's too much to expect a user to
>>
2016-08-05 22:51 GMT+02:00 Lauri Kenttä :
> On 2016-08-05 21:20, Charles R. Portwood II wrote:
>
>> On Fri, Aug 5, 2016 at 12:12 PM, Tom Worster wrote:
>>
>>>
>>> I can understand an argument that it's too much to expect a user to
>>> provide an options array when using Argon2. But I don't unders
On 2016-08-05 21:20, Charles R. Portwood II wrote:
On Fri, Aug 5, 2016 at 12:12 PM, Tom Worster wrote:
I can understand an argument that it's too much to expect a user to
provide an options array when using Argon2. But I don't understand how
my
suggestion breaks BC. In my idea, a future RFC w
On Fri, Aug 5, 2016 at 12:12 PM, Tom Worster wrote:
>
> I can understand an argument that it's too much to expect a user to
> provide an options array when using Argon2. But I don't understand how my
> suggestion breaks BC. In my idea, a future RFC would propose default cost
> constants. Changing
2016-08-05 18:36 GMT+02:00 Charles R. Portwood II <
charlesportwoo...@erianna.com>:
> On Fri, Aug 5, 2016 at 10:08 AM, Ryan Pallas wrote:
> >
> >
> > I think this is the most important part to consider. If you make $options
> > required for this algo, then making this algo the PASSWORD_DEFAULT wo
On 8/5/16, 12:36 PM, "Charles R. Portwood II"
wrote:
>I understand what you're saying. Ryan said it a bit more clearly than I
>did, making the options required causes backwards-incompatible changes to
>the password_hash API. That's my real reservation behind not providing
>defaults.
>
>A separat
On Fri, Aug 5, 2016 at 10:08 AM, Ryan Pallas wrote:
>
>
> I think this is the most important part to consider. If you make $options
> required for this algo, then making this algo the PASSWORD_DEFAULT would
> mean that its a backwards incompatible change, because now all calls to
> password_hash($
On 8/5/16, 11:08 AM, "Ryan Pallas" wrote:
>Please keep it so that defaults will work, but $options is available for
>tuning as that's how the feature currently works.
My suggestion doesn't affect that. I agree that password_hash($password,
PASSWORD_DEFAULT) should always "just work".
Instead, I
On Fri, Aug 5, 2016 at 8:49 AM, Charles R. Portwood II <
charlesportwoo...@erianna.com> wrote:
> On Fri, Aug 5, 2016 at 9:19 AM, Tom Worster wrote:
>
> > On 8/5/16 8:47 AM, Charles R. Portwood II wrote:
>
> Finally, I wonder if it wouldn't be better if, for the time being, we
> > do not provide d
16 matches
Mail list logo
