pet...@riseup.net (2018-04-03 14:32):
| In the meantime I hit into this:
|
| https://github.com/Lyndir/MasterPassword/
|
| […]
|
| 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.
https://tonyarcieri.com/4-fa
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.
If you change your master password you have to change every single one
of your accounts.
If one account gets broken into you either:
1) have to store metada
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 fur
*** Markus Teich [2018-03-10 21:29]:
>You are correct that it doesn't hurt to add a MAC. I was thinking it wouldn't
>make sense to authenticate to myself. Could you point me to an attack
>scenario
>where not having a MAC in this scheme is bad?
Actually I can not. Well, those data could be forged b
Am 2018-03-11 01:48, schrieb Sergey Matveev:
*** Markus Teich [2018-03-10 17:09]:
I don't know crypto_argon2i. I'd use the standardized HKDF2 scheme to
derive
the key.
HKDF algorithm is not aimed to be used with passwords. It is ok to be
used with Diffie-Hellman outputs for example. Password-
Am 2018-03-11 04:21, schrieb Anselm Garbe:
On 10 March 2018 at 06:08, Markus Teich
wrote:
Should be fine, but the salt should not be secret (you need to sync it
between devices where you want to use this system after all). The
point is
that you can give your encrypted database as it is stored
Hi Markus,
On 10 March 2018 at 06:08, Markus Teich wrote:
> Should be fine, but the salt should not be secret (you need to sync it
> between devices where you want to use this system after all). The point is
> that you can give your encrypted database as it is stored on disk to anyone
> and they
*** Markus Teich [2018-03-10 17:09]:
>I don't know crypto_argon2i. I'd use the standardized HKDF2 scheme to derive
>the key.
HKDF algorithm is not aimed to be used with passwords. It is ok to be
used with Diffie-Hellman outputs for example. Password-derived keys are
required (ideally) to use CPU a
*** Michael Forney [2018-03-08 22:10]:
>I'm no expert either (so follow this at your own risk), but I also did
>some investigation, and I think either of the following schemes would
>work:
>(1)
This scheme seems ok and some kind of classical one. Simple and working.
>It's not clear to me if it's
(1)
Setup:
- Generate a random salt and store somewhere safe.
Note that it should not be required to keep the salt secret.
Encryption:
- Read the salt from its location and the master password from the
console. Use those to generate a key with crypto_argon2i.
I don't know crypto_argon2i. I'd
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 s
On 2018-03-07, pet...@riseup.net wrote:
> 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
On 2018-03-07, pet...@riseup.net wrote:
> On 2018-03-07 00:23, Michael Forney wrote:
>> Another related project I've been following is https://monocypher.org/
>>
>> It has a quite permissive license and encourages inlining the source
>> like you want.
>
> Hi Michael,
>
> thanks, this looks really
On 2018-03-08 06:57, Markus Teich wrote:
> pet...@riseup.net wrote:
>> I have to yet read up if it is safe to use
>> with a single key, i.e. encrypting n passwords with the same secret key.
>
> Make sure to use salting in this case. Otherwise using the same
> password for multiple sites/keys would
pet...@riseup.net wrote:
I have to yet read up if it is safe to use
with a single key, i.e. encrypting n passwords with the same secret
key.
Make sure to use salting in this case. Otherwise using the same password
for multiple sites/keys would be visible.
You also want to hide the keys them
On 2018-03-06 9:09 am, harry666t wrote:
So yes, the entire password store should be kept in one encrypted file
and so it can be opened and closed.
And then merges become a total pain. You might as well use Keepass.
I don't see why this must be so. Just decrypt the password store, merge,
and
On 2018-03-06 9:01 am, Truls Becken wrote:
Some libraries to look at are; libressl, libtomcrypt, nacl.cr.yp.to,
libsodium, nettle, libgcrypt and libmcrypt.
Has anyone here seen or mentioned bearssl? [https://bearssl.org/] It
looks like it meshes with the suckless philosophy quite effectively.
On 2018-03-07 00:23, Michael Forney wrote:
> Another related project I've been following is https://monocypher.org/
>
> It has a quite permissive license and encourages inlining the source
> like you want.
Hi Michael,
thanks, this looks really nice and small. I'm doing my homework reading
crypto
On 2018-03-06, pet...@riseup.net wrote:
> On 2018-03-06 10:01, Truls Becken wrote:
>> Some libraries to look at are; libressl, libtomcrypt, nacl.cr.yp.to,
>> libsodium, nettle, libgcrypt and libmcrypt.
>
> Hello Truls,
>
> thank you for this list. I was hoping there would be a publicly
> available
On 2018-03-06 10:01, Truls Becken wrote:
> Some libraries to look at are; libressl, libtomcrypt, nacl.cr.yp.to,
> libsodium, nettle, libgcrypt and libmcrypt.
Hello Truls,
thank you for this list. I was hoping there would be a publicly
available algo that could be inlined in the source since I rea
Hi Thomas,
On 2018-03-06 00:57, Thomas Levine wrote:
> If you copy (vendor) an encryption/decryption algorithm into your source
> code, then you are relying on more than libc. So perhaps you could
> expand your dependencies to libraries with acceptable licensing or
> to libraries that are widely a
> So yes, the entire password store should be kept in one encrypted file
> and so it can be opened and closed.
And then merges become a total pain. You might as well use Keepass.
Some libraries to look at are; libressl, libtomcrypt, nacl.cr.yp.to,
libsodium, nettle, libgcrypt and libmcrypt.
, pet...@riseup.net
Subject: Re: [dev] securiy guidance
Maybe this is off-topic, but I have to make a few corrections.
On Tue, Mar 6, 2018 at 12:57 AM, Thomas Levine <_...@thomaslevine.com> wrote:
>
> It still uses gpg, but it forces a particular simplified style of usage
> that should
If you copy (vendor) an encryption/decryption algorithm into your source
code, then you are relying on more than libc. So perhaps you could
expand your dependencies to libraries with acceptable licensing or
to libraries that are widely available. For example, OpenBSD 6.2
provides blowfish. Also, Gn
On 2018-03-05 15:15, Kart Etlinger wrote:
> Well, all those problems can be solved by pass-tomb addon, but it uses
> zsh, which may be some problem for people who dislike zsh as coding
> language.
> So yes, the entire password store should be kept in one encrypted file
> and so it can be opened and
Well, all those problems can be solved by pass-tomb addon, but it uses
zsh, which may be some problem for people who dislike zsh as coding
language.
So yes, the entire password store should be kept in one encrypted file
and so it can be opened and closed.
On 03/05/2018 12:16 PM, Truls Becken wrote
Hi Peter,
I know this is not what you asked about, but there is one other thing people
dislike about pass; the file hierarchy is in plain text. If you can fix that,
you might attract some users.
-Truls
On Mon, Mar 5, 2018 at 11:06 AM, wrote:
> Hello,
>
> this mail won't be related to any suckl
Hello,
this mail won't be related to any suckless projects, I am looking for
some guidance/tips. If this isn't a good place for such requests I can
take a hint.
Since I stumbled upon suckless.org (2-3 weeks) I switched to dwm and st,
read the philosophy and many other pages, browsed through some
29 matches
Mail list logo
