On 2018-03-10 03:59, Markus Teich wrote:
> Am 2018-03-08 18:47, schrieb pet...@riseup.net:
>> Looking at the chacha API one needs to use a nonce, in the monocypher
>> implementation it is 24 bits wide, which would give the option of almost
>> 17M runs with a single key. IIUC adding a salt would further randomize
>> the output and possibly prevent some other forms of attacks but won't
>> replace the nonce as the salt cannot be secret either.
>
> I don't know the chacha API. Please check the wikipedia pages for salt
> vs. nonce.
> TLDR: They are similar, but for passwords the term salt is used while
> nonce is used
> in network protocol context. An important difference is that the salt is
> always
> okay to publish/store, while some nonces have to be kept secret.
> However the "only
> use once" concept also applies to salts, so make sure you generate a
> new salt each
> time you recompute the hash of a key/password.
>
>> What is a profiling attack? A quick search didn't bring up anything
>> relevant. I see many people are disturbed by the idea that the keys of
>> the password key-value store are visible on the filesystem. I will have
>> to think about that.
>
> I don't know if there is a specific term for this. You want your
> system to be good
> enough that you can publish the encrypted password database (Kerckhoffs's 2nd
> principle). For my project I envisioned using git for db synchronization. So
> if
> the keys ("google.com", "facebook.com", "nastypr0nsite.sexy", …) are
> not encrypted
> equally well, everyone can see where you have accounts. That's what people are
> concerned about.
>
>> In the meantime I am realizing that security is really, really hard. All
>> the sorts of attacks there are, memory swapping, wiping disk and memory
>> properly after finished... And I haven't even gotten to the agent part,
>> which needs to store the password in memory. Thinking about that part
>> I'm not even sure how can that be done safely. Well, at least I
>> understand better why are people relying on GPG to do that part. Lesson
>> learned :)
>
> Well it is hard indeed, but it's also interesting to learn all that stuff.
> If you don't push your first attempts at cryptography to thousands of users,
> it is usually fine. After all, the best way to learn is to make mistakes. You
> just have to accept that you will definitely be making mistakes and willing to
> fix them. :)
A bit of a necromancer reply :) Other ideas, family responsibilities and
the seeming complexity of this tool have made me diverge from this
project, maybe just temporarily, we'll see.
In the meantime I hit into this:
https://github.com/Lyndir/MasterPassword/
To quote a small chapter for the lazy ones:
> Master Password simply uses your one password and the name of the site to
> generate a site-specific secret.
> Master Password can derive the site-password in an entirely stateless manner.
> It is therefore better defined as a calculator than a manager. It is the
> user's responsibility to remember the inputs: user-name,
> master-password, site-name, site-counter and site-template.
> We standardize user-name as your full name, site-name as the domain name of
> the site, site-counter to 1 (unless you explicitly increment it) and
> site-template to Long Password; as a result the only token the user really
> needs to remember actively is master-password.
Any thoughts why this isn't the perfect solution? I thought about it for
a while and all the cons that I could come up with were false.
--
------------
Peter Nagy
------------
