On Fri, Jun 02, 2017 at 09:12:40AM -0700, Mike Pontillo wrote:
> So I don't particularly mind what the key derivation algorithm is, because
> it's not even password-based at all, which makes it inherently stronger.
> The MAAS shared secret is 16 random bytes, so brute force attacks are
> already im
On Fri, Jun 2, 2017 at 1:09 AM, John A Meinel
wrote:
> Note also that I do have a stake here, as this is what we do for Juju. Its
> perfectly fine to wait 1s for a user-initiated login to get a response. But
> when you have 1000 agents that are restarting at the same time because you
> bounced th
On Jun 2, 2017 11:02, "Mike Pontillo" wrote:
On Thu, Jun 1, 2017 at 6:28 PM, Dustin Kirkland
wrote:
> For a while, I ran my MAAS controllers on a rpi2.
>
> Eventually, I abandoned that architecture, once I switched to MAAS HA,
> and tried to instantiate a second MAAS server in a LXD container o
On Fri, Jun 2, 2017 at 1:09 AM, John A Meinel
wrote:
> Note also that I do have a stake here, as this is what we do for Juju. Its
> perfectly fine to wait 1s for a user-initiated login to get a response. But
> when you have 1000 agents that are restarting at the same time because you
> bounced th
On Fri, Jun 2, 2017 at 1:05 AM, John Meinel wrote:
> I'll note that if you're generating a password, there really isn't a
> reason to then pbkdf2 it, is there? I thought the reason to use pbkdf2 was
> because it is too easy to generate SHA hashes for common *human* passwords.
> But as the brute-f
On Thu, Jun 1, 2017 at 7:59 PM, Seth Arnold
wrote:
> PBKDF2 is also fairly old; I believe most cryptographers would prefer
> argon2, scrypt, or bcrypt to PBKDF2, with a grudging acceptance that if
> you have to sell into the FIPS marketplace you may not have a choice.
> Do we have a choice?
>
It
On Thu, Jun 1, 2017 at 6:28 PM, Dustin Kirkland
wrote:
> For a while, I ran my MAAS controllers on a rpi2.
>
> Eventually, I abandoned that architecture, once I switched to MAAS HA,
> and tried to instantiate a second MAAS server in a LXD container on an
> x86_64 server. As it turns out, Postgre
Note also that I do have a stake here, as this is what we do for Juju. Its
perfectly fine to wait 1s for a user-initiated login to get a response. But
when you have 1000 agents that are restarting at the same time because you
bounced the controller machine, it takes a *long* time for them all to ge
I'll note that if you're generating a password, there really isn't a reason
to then pbkdf2 it, is there? I thought the reason to use pbkdf2 was because
it is too easy to generate SHA hashes for common *human* passwords. But as
the brute-force search spaces increases exponentially with more bits, ju
On Fri, 2 Jun 2017 at 01:47 Mike Pontillo
wrote:
[...]
> only tested a few different x86_64 nodes thus far. It would be good to get
> an idea how slow other less-common architectures can be. If answers could
> be in the following format, that would be appreciated:
>
> Derivation time: x.xx se
Derivation time: 0.8s
Architecture: x86_64
Model name:QEMU Virtual CPU version 0.12
Derivation time: 0.9s
Architecture: x86_64
Model name:Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
Derivation time: 1,3-1,6s
Architecture: x86_64
Model name:
11 matches
Mail list logo
