Mailing List Archive

On Tuesday, 19 September 2023 06:36:13 BST Dale wrote:
> Howdy,
>
> As some know, I encrypt a lot of stuff here. I use passwords that I can
> recall but no one could ever guess. I don't use things that someone may
> figure out like pet's name or anything like that. I use a couple sites
> to see just how good my passwords are. I try to get into the millions
> of years at least. I have a couple that it claims is in the trillions
> of years to crack. I've read some things not to use like pet names and
> such. I've also read that one should use upper and lower case letters,
> symbols and such and I do that, especially on my stuff I never want to
> be cracked. Some stuff, when I'm dead, it's gone.

As/when quantum computers development progresses, many/some passwords and
hashes will be cracked/brute forced (RSA encryption springs to mind). It is
best if you can think of any password as keeping your door and windows locked.
They will stop most opportunistic attempts, but not anyone who is determined
to break in. It is unlikely your passwords will stop state actors. A strong
password, like a strong door lock, buys you time. Hence the general
recommendation to change your passwords frequently.


> In the real world tho, how do people reading this make passwords that no
> one could ever guess?

You can use gpg, or openssl, or app-admin/apg, or app-admin/pwgen, to generate
random enough strings to use as passwords. They will be difficult to guess,
but will be VERY difficult to remember. You'll have to store them offline
and/or protect them in turn with some master passphrase you can remember.

As an example, you could choose characters/strings from the output stored in
file.txt, when you run:

< /dev/random tr -dc "[:space:][:print:]" | head -c500 > file.txt


> I use Bitwarden to handle website passwords and
> it does a good job. I make up my own tho when encrypting drives. I'm
> not sure I can really use Bitwarden for that given it is a command line
> thing, well, in a script in my case. I doubt anyone would ever guess
> any of my passwords but how do people reading this do theirs? Just how
> far do you really go to make it secure? Obviously you shouldn't give up
> much detail but just some general ideas. Maybe even a example or two of
> a fake password, just something that you would come up with and how.
>
> This is the two sites I use.
>
>
> https://www.passwordmonster.com/
>
> https://www.security.org/how-secure-is-my-password/
>
>
> I have a password in the first one that shows this:
>
>
> It would take a computer about 63 thousand years to crack your password
>
>
> Second one says this.
>
> It would take a computer about 5 million years to crack your password
>
> Exact same password in both. Why such a large range to crack?

I don't know why these guys come up with different years-equivalent strength,
but I tend to treat such websites as suspicious. They are more likely to act
as a honeypot to *record* your passwords, than provide you with truly
meaningful information. I suppose you could use them to test an example of a
password you would never use thereafter, but even this could reveal some
underlying pattern in how you structure your passwords.


> I tend
> to use the first site to create a password. Then I test it in the
> second site to sort of confirm it. If both say a long time, then I got
> a fairly good one depending on what I'm protecting. Still, why such a
> difference? One reason I use the first site, I can make it show the
> password. The second site doesn't do that so editing it to improve
> things is harder since you can't see it. The first site makes that easy
> and gives me a idea of whether I'm on the right track. Second site
> confirms it. I did contact the second site and ask for a button to show
> the password. After all, no one is here but me. My windows are covered.
>
> Also, I use cryptsetup luksFormat -s 512 ... to encrypt things. Is
> that 512 a good number? Can it be something different? I'd think since
> it is needed as a option, it can have different values and encrypt
> stronger or weaker. Is that the case? I've tried to find out but it
> seems everyone uses 512. If that is the only value, why make it a
> option? I figure it can have other values but how does that work?

The size of key options depend on the block cipher. A larger key size tends
to be stronger, but its processing slower. Embedded devices without hardware
accelerated crypto could struggle with larger key sizes.


> Heck, a link to some good info on that would be good. :-)

https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md

https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf

https://wiki.archlinux.org/title/Data-at-rest_encryption

Am 19.09.23 um 07:36 schrieb Dale:
> Maybe even a example or two of a fake password, just something that you
> would come up with and how.


There was this TV series Sherlock. In one episode they communicated by
numbers where each number referred to a word in a book. This was
somewhat also used in a movie with Nicolas Cage where he is treasure
hunting.

For the passwords which matter this seems to be a quit good way. As long
as nobody guesses your book you can write down your passwords and look
them up if needed. Like 239/4 which would tell you to open page 239 and
use word 4. Or 239/4/3 -> page 239 line 4 word 3.
Then you start to make it difficult so that you don't just use words.
Like start with the first letter of the word than go backwards and use
every second letter until you habe 8 letters. Mix in a number for every
third position.
You can change the rule as you like. Keep it always the same and you can
look your password up every time. In German there are quit a lot of
capital letters so just take them.
You can be creative as wild. Take a poem in middle age German and take
only the first an last letter from every line. Every third number from
pi. Since there is no pattern in pi this should be safe.

Something like that.

I generate random passwords using dice. First and last characters in
passwords are letters that's arbitrary buys more time. Those should have
lengths over 13 and before the agency I used to work for went to
smartcards and 256 character random passwords their last standard was 16
characters with minimum two symbols minimum two numbers minimum two
upper-case and minimum two lower-case. No dictionary words or keyboard
walking allowed. Firewall piercing with laptops got used regularly by
state actors and there is a firewall-piercing-howto file on the internet
for anyone interested.
The remaining characters first got their sets chosen. A 1 on dice picked
a number for that spot and a 6 picked a symbol. Two or 3 picked an
upper-case and 4 or 5 picked a lower-case. Once the set spots got figured
five dice got used for letters add the total and subtract 4 for the
particular letter. three dice got used for symbols with a single dice
roll of either odd for first 16 symbols or even single dice roll for
second 16 symbols. Your choice as to put which 16 symbols in the even and
odd sets those could be randomized. Numbers used two dice with 2
subtracted from total and a 2 rolled with the dice returned a 0. Slow and
necessary to write worksheet down as dice rolling proceeded and password
needed writing down on completion. Since I do most of my writing in
braille I have a good encryption system I can encrypt further by using the
old English braille instead of the American braille. American braille has
dot arrangement 123 down left side of cell for reading and 4 5 6 down
right side of cell for reading. English braille has 1 3 5 down the left
side and 2 4 6 down the right side of the cell for reading. Those are dot
number arrangements. Braille readers on this list I expect maybe only one
other will understand what I just wrote.


-- Jude <jdashiel at panix dot com> "There are four boxes to be used in
defense of liberty: soap, ballot, jury, and ammo. Please use in that
order." Ed Howdershelt 1940.

On Tue, 19 Sep 2023, Michael wrote:

> On Tuesday, 19 September 2023 06:36:13 BST Dale wrote:
> > Howdy,
> >
> > As some know, I encrypt a lot of stuff here. I use passwords that I can
> > recall but no one could ever guess. I don't use things that someone may
> > figure out like pet's name or anything like that. I use a couple sites
> > to see just how good my passwords are. I try to get into the millions
> > of years at least. I have a couple that it claims is in the trillions
> > of years to crack. I've read some things not to use like pet names and
> > such. I've also read that one should use upper and lower case letters,
> > symbols and such and I do that, especially on my stuff I never want to
> > be cracked. Some stuff, when I'm dead, it's gone.
>
> As/when quantum computers development progresses, many/some passwords and
> hashes will be cracked/brute forced (RSA encryption springs to mind). It is
> best if you can think of any password as keeping your door and windows locked.
> They will stop most opportunistic attempts, but not anyone who is determined
> to break in. It is unlikely your passwords will stop state actors. A strong
> password, like a strong door lock, buys you time. Hence the general
> recommendation to change your passwords frequently.
>
>
> > In the real world tho, how do people reading this make passwords that no
> > one could ever guess?
>
> You can use gpg, or openssl, or app-admin/apg, or app-admin/pwgen, to generate
> random enough strings to use as passwords. They will be difficult to guess,
> but will be VERY difficult to remember. You'll have to store them offline
> and/or protect them in turn with some master passphrase you can remember.
>
> As an example, you could choose characters/strings from the output stored in
> file.txt, when you run:
>
> < /dev/random tr -dc "[:space:][:print:]" | head -c500 > file.txt
>
>
> > I use Bitwarden to handle website passwords and
> > it does a good job. I make up my own tho when encrypting drives. I'm
> > not sure I can really use Bitwarden for that given it is a command line
> > thing, well, in a script in my case. I doubt anyone would ever guess
> > any of my passwords but how do people reading this do theirs? Just how
> > far do you really go to make it secure? Obviously you shouldn't give up
> > much detail but just some general ideas. Maybe even a example or two of
> > a fake password, just something that you would come up with and how.
> >
> > This is the two sites I use.
> >
> >
> > https://www.passwordmonster.com/
> >
> > https://www.security.org/how-secure-is-my-password/
> >
> >
> > I have a password in the first one that shows this:
> >
> >
> > It would take a computer about 63 thousand years to crack your password
> >
> >
> > Second one says this.
> >
> > It would take a computer about 5 million years to crack your password
> >
> > Exact same password in both. Why such a large range to crack?
>
> I don't know why these guys come up with different years-equivalent strength,
> but I tend to treat such websites as suspicious. They are more likely to act
> as a honeypot to *record* your passwords, than provide you with truly
> meaningful information. I suppose you could use them to test an example of a
> password you would never use thereafter, but even this could reveal some
> underlying pattern in how you structure your passwords.
>
>
> > I tend
> > to use the first site to create a password. Then I test it in the
> > second site to sort of confirm it. If both say a long time, then I got
> > a fairly good one depending on what I'm protecting. Still, why such a
> > difference? One reason I use the first site, I can make it show the
> > password. The second site doesn't do that so editing it to improve
> > things is harder since you can't see it. The first site makes that easy
> > and gives me a idea of whether I'm on the right track. Second site
> > confirms it. I did contact the second site and ask for a button to show
> > the password. After all, no one is here but me. My windows are covered.
> >
> > Also, I use cryptsetup luksFormat -s 512 ... to encrypt things. Is
> > that 512 a good number? Can it be something different? I'd think since
> > it is needed as a option, it can have different values and encrypt
> > stronger or weaker. Is that the case? I've tried to find out but it
> > seems everyone uses 512. If that is the only value, why make it a
> > option? I figure it can have other values but how does that work?
>
> The size of key options depend on the block cipher. A larger key size tends
> to be stronger, but its processing slower. Embedded devices without hardware
> accelerated crypto could struggle with larger key sizes.
>
>
> > Heck, a link to some good info on that would be good. :-)
>
> https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md
>
> https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf
>
> https://wiki.archlinux.org/title/Data-at-rest_encryption
>

hitachi303 wrote:
> Am 19.09.23 um 07:36 schrieb Dale:
>> Maybe even a example or two of a fake password, just something that
>> you would come up with and how.
>
>
> There was this TV series Sherlock. In one episode they communicated by
> numbers where each number referred to a word in a book. This was
> somewhat also used in a movie with Nicolas Cage where he is treasure
> hunting.
>
> For the passwords which matter this seems to be a quit good way. As
> long as nobody guesses your book you can write down your passwords and
> look them up if needed. Like 239/4 which would tell you to open page
> 239 and use word 4. Or 239/4/3 -> page 239 line 4 word 3.
> Then you start to make it difficult so that you don't just use words.
> Like start with the first letter of the word than go backwards and use
> every second letter until you habe 8 letters. Mix in a number for
> every third position.
> You can change the rule as you like. Keep it always the same and you
> can look your password up every time. In German there are quit a lot
> of capital letters so just take them.
> You can be creative as wild. Take a poem in middle age German and take
> only the first an last letter from every line. Every third number from
> pi. Since there is no pattern in pi this should be safe.
>
> Something like that.
>
>


I like the Sherlock stuff.  Everything from the black and white
versions, 1950's, to the TV series Elementary which is more recent. 
That is a idea but I currently come up with them from things I have or
weird things I won't forget.  Models of vehicles or some other thing I
have and will have for a long time.  Some are a little short but those
password sites say they are good strong passwords. 

That's a interesting way to come up with passwords tho.  I've seen that
is a few whodunit type shows.  Way back in the old days, they had some
interesting ways of coding messages.  Passwords are sort of similar. 

I'll have to give that some thought.  It's not how I usually do it but
it is interesting. 

Thanks.

Dale

:-)  :-) 

another possibility is use of a dictionary. Find a word in dictionary
note page column and line. Divide pages in dictionary by 2 and either add
or subtract that number of pages to or from page word is found on then on
the new page find the column and line for your actual password. Of
course, you write the first word you looked up down as your password and
not the second word you just found you use for your real password.


-- Jude <jdashiel at panix dot com> "There are four boxes to be used in
defense of liberty: soap, ballot, jury, and ammo. Please use in that
order." Ed Howdershelt 1940.

On Tue, 19 Sep 2023, hitachi303 wrote:

> Am 19.09.23 um 07:36 schrieb Dale:
> > Maybe even a example or two of a fake password, just something that you
> > would come up with and how.
>
>
> There was this TV series Sherlock. In one episode they communicated by numbers
> where each number referred to a word in a book. This was somewhat also used in
> a movie with Nicolas Cage where he is treasure hunting.
>
> For the passwords which matter this seems to be a quit good way. As long as
> nobody guesses your book you can write down your passwords and look them up if
> needed. Like 239/4 which would tell you to open page 239 and use word 4. Or
> 239/4/3 -> page 239 line 4 word 3.
> Then you start to make it difficult so that you don't just use words. Like
> start with the first letter of the word than go backwards and use every second
> letter until you habe 8 letters. Mix in a number for every third position.
> You can change the rule as you like. Keep it always the same and you can look
> your password up every time. In German there are quit a lot of capital letters
> so just take them.
> You can be creative as wild. Take a poem in middle age German and take only
> the first an last letter from every line. Every third number from pi. Since
> there is no pattern in pi this should be safe.
>
> Something like that.
>
>

On Tue, Sep 19, 2023 at 4:26?AM Michael <confabulate@kintzios.com> wrote:
>
> On Tuesday, 19 September 2023 06:36:13 BST Dale wrote:
> > Howdy,
> >
> A strong
> password, like a strong door lock, buys you time. Hence the general
> recommendation to change your passwords frequently.

While that can help on websites, it is of no use for full disk
encryption passwords - at least not without jumping through some big
hoops.

In order to crack your LUKS password somebody obviously needs to be
able to read the encrypted contents of your disk. They cannot begin
cracking it until they have a copy of the LUKS headers. However, once
they do have it, they can make a copy and crack it at their leisure.
If they manage to crack it, then it will give them the volume key. At
that point if they were able to make a full copy of your disk they can
read whatever was on it at the time. If they can make a fresh copy of
your disk then changing the passphrase will not change the volume key,
and so they'll be able to read what is currently on your disk.

Changing the volume key would defeat this, but requires running
cryptsetup-reencrypt which will take considerable time/CPU, though it
sounds like it can be done online.

> > In the real world tho, how do people reading this make passwords that no
> > one could ever guess?

You didn't ask this question, but I'll just note that most
organizations don't use human-readable passwords to implement full
disk encryption. The most commonly used solution is to use a TPM to
measure the boot process and secure the disk encryption keys. If the
system is booted normally, the bootloader can read the encryption keys
from the TPM and can decrypt the disk without any user interaction (or
even awareness it is happening). If the system is booted from
alternative media, or the on-disk bootloader is tampered with, or even
if the firmware is tampered with, then the TPM measurements will not
agree with those used to store the key, and the TPM will not allow the
keys to be read.

This is how solutions like Bitlocker work.

The components for this exist in the Linux world, but I'm not aware of
any distro/etc actually implementing this with a pretty front-end, and
there are obviously details that need to be carefully handled so that
a bootloader or firmware update doesn't render your disk unreadable.
Typically software implementations have ways to store "recovery keys"
for these situations (just another copy of the disk key stored outside
the TPM).

> You can use gpg, or openssl, or app-admin/apg, or app-admin/pwgen, to generate
> random enough strings to use as passwords.

You might want to also consider app-admin/xkcdpass

> > Also, I use cryptsetup luksFormat -s 512 ... to encrypt things. Is
> > that 512 a good number? Can it be something different? I'd think since
> > it is needed as a option, it can have different values and encrypt
> > stronger or weaker. Is that the case? I've tried to find out but it
> > seems everyone uses 512. If that is the only value, why make it a
> > option? I figure it can have other values but how does that work?

You can use a different size, but 512b is the recommended value for
the default cipher. It is also the default I believe, so there isn't
much point in passing it. Actually, I'd consider passing that
parameter harmful unless you also specify the cipher. If in the
future the default changes to some other cipher, perhaps 512b will no
longer be appropriate, and you'll weaken it by specifying one and not
the other.

If you just want to trust the defaults, then trust the defaults.

As to why 512b is the recommendation, that seems like it would require
a LOT more reading. Apparently it is in an IEEE standard and I'd need
to grok a lot more crypto to appreciate it.

--
Rich

Hmmmm,

For some reason, I didn't get Michael's email.  I see him being quoted
but don't have his original.  I wonder what is up with that.  O-o


Rich Freeman wrote:
> On Tue, Sep 19, 2023 at 4:26?AM Michael <confabulate@kintzios.com> wrote:
>> On Tuesday, 19 September 2023 06:36:13 BST Dale wrote:
>>> Howdy,
>>>
>> A strong
>> password, like a strong door lock, buys you time. Hence the general
>> recommendation to change your passwords frequently.
> While that can help on websites, it is of no use for full disk
> encryption passwords - at least not without jumping through some big
> hoops.
>
> In order to crack your LUKS password somebody obviously needs to be
> able to read the encrypted contents of your disk. They cannot begin
> cracking it until they have a copy of the LUKS headers. However, once
> they do have it, they can make a copy and crack it at their leisure.
> If they manage to crack it, then it will give them the volume key. At
> that point if they were able to make a full copy of your disk they can
> read whatever was on it at the time. If they can make a fresh copy of
> your disk then changing the passphrase will not change the volume key,
> and so they'll be able to read what is currently on your disk.
>
> Changing the volume key would defeat this, but requires running
> cryptsetup-reencrypt which will take considerable time/CPU, though it
> sounds like it can be done online.
>


Let's jump into a hypothetical here.  Let's say I'm a nasty terrorist or
some other really evil dude.  Let's say I have passwords are that really
good.  Let's say around 20 characters and a really nice mix of
characters.  If some gov't agency got my hard drive, how long would it
take for them to crack it?  I know when Snowden released all that info,
there was some changes to encryption.  Still, do they have the ability
to crack them without much trouble?  Is there something better to use
than what I'm using now?

I might add, when I configured my three drive setup, I sort of did it a
different way.  I still used cryptsetup but I used it later in the
process.  I also made sure to put the luks bit in.  That way I can
change passwords if needed.  I found a new howto and it seems to end the
same way but it's done in layers.  Luks first and then encryption but
different somehow.  Mostly, I can change passwords on it.  I don't
really get the whole thing, yet.  If I read it enough, my light bulb
will come on.  o_O 


>
>>> Also, I use cryptsetup luksFormat -s 512 ... to encrypt things. Is
>>> that 512 a good number? Can it be something different? I'd think since
>>> it is needed as a option, it can have different values and encrypt
>>> stronger or weaker. Is that the case? I've tried to find out but it
>>> seems everyone uses 512. If that is the only value, why make it a
>>> option? I figure it can have other values but how does that work?
> You can use a different size, but 512b is the recommended value for
> the default cipher. It is also the default I believe, so there isn't
> much point in passing it. Actually, I'd consider passing that
> parameter harmful unless you also specify the cipher. If in the
> future the default changes to some other cipher, perhaps 512b will no
> longer be appropriate, and you'll weaken it by specifying one and not
> the other.
>
> If you just want to trust the defaults, then trust the defaults.
>
> As to why 512b is the recommendation, that seems like it would require
> a LOT more reading. Apparently it is in an IEEE standard and I'd need
> to grok a lot more crypto to appreciate it.
>

Well, I was wondering if it could be set to 1024 and it make the
encryption stronger or something.  I've searched but no one explains
what that number really does other than set something.  Since that is
the default, I guess I can leave that out of my command.  Save me some
typing.  Anyway, 512 it is. 

Dale

:-)  :-) 

Jude DaShiell wrote:
> another possibility is use of a dictionary. Find a word in dictionary
> note page column and line. Divide pages in dictionary by 2 and either add
> or subtract that number of pages to or from page word is found on then on
> the new page find the column and line for your actual password. Of
> course, you write the first word you looked up down as your password and
> not the second word you just found you use for your real password.
>
>
> -- Jude <jdashiel at panix dot com> "There are four boxes to be used in
> defense of liberty: soap, ballot, jury, and ammo. Please use in that
> order." Ed Howdershelt 1940.
>
>


I think I've seen that used for messages ages ago.  It's a way of
sending info that without knowing how to decode it and the same version
of dictionary, you have no idea what it says.  Just don't lose the book
you use. 

The responses I'm getting sure are interesting.  Some I've seen but
never thought of using myself.  After all, it was a TV show, sometimes a
history documentary or something.  Reading about it here, it makes sense. 

Oh, like the signature too.  ;-)

Dale

:-)  :-) 

On Tuesday, 19 September 2023 12:13:40 BST Dale wrote:
> Hmmmm,
>
> For some reason, I didn't get Michael's email. I see him being quoted
> but don't have his original. I wonder what is up with that. O-o

Assuming you will receive this message, have a look here:

https://marc.info/?l=gentoo-user&m=169511184714476&w=2


> Rich Freeman wrote:
> > On Tue, Sep 19, 2023 at 4:26?AM Michael <confabulate@kintzios.com> wrote:
> >> On Tuesday, 19 September 2023 06:36:13 BST Dale wrote:
> >>> Howdy,
> >>
> >> A strong
> >> password, like a strong door lock, buys you time. Hence the general
> >> recommendation to change your passwords frequently.
> >
> > While that can help on websites, it is of no use for full disk
> > encryption passwords - at least not without jumping through some big
> > hoops.
> >
> > In order to crack your LUKS password somebody obviously needs to be
> > able to read the encrypted contents of your disk. They cannot begin
> > cracking it until they have a copy of the LUKS headers. However, once
> > they do have it, they can make a copy and crack it at their leisure.
> > If they manage to crack it, then it will give them the volume key. At
> > that point if they were able to make a full copy of your disk they can
> > read whatever was on it at the time. If they can make a fresh copy of
> > your disk then changing the passphrase will not change the volume key,
> > and so they'll be able to read what is currently on your disk.
> >
> > Changing the volume key would defeat this, but requires running
> > cryptsetup-reencrypt which will take considerable time/CPU, though it
> > sounds like it can be done online.
>
> Let's jump into a hypothetical here. Let's say I'm a nasty terrorist or
> some other really evil dude. Let's say I have passwords are that really
> good. Let's say around 20 characters and a really nice mix of
> characters. If some gov't agency got my hard drive, how long would it
> take for them to crack it?

A couple of minutes?

https://xkcd.com/538/

:-)

Am 19.09.23 um 13:47 schrieb Michael:
> A couple of minutes?
>
> https://xkcd.com/538/
>
> ????

Most crypto nerds have a wrench at home. The gov. can even save those 5$.
:-)

Jude DaShiell wrote:
> I generate random passwords using dice. First and last characters in
> passwords are letters that's arbitrary buys more time. Those should have
> lengths over 13 and before the agency I used to work for went to
> smartcards and 256 character random passwords their last standard was 16
> characters with minimum two symbols minimum two numbers minimum two
> upper-case and minimum two lower-case. No dictionary words or keyboard
> walking allowed. Firewall piercing with laptops got used regularly by
> state actors and there is a firewall-piercing-howto file on the internet
> for anyone interested.
> The remaining characters first got their sets chosen. A 1 on dice picked
> a number for that spot and a 6 picked a symbol. Two or 3 picked an
> upper-case and 4 or 5 picked a lower-case. Once the set spots got figured
> five dice got used for letters add the total and subtract 4 for the
> particular letter. three dice got used for symbols with a single dice
> roll of either odd for first 16 symbols or even single dice roll for
> second 16 symbols. Your choice as to put which 16 symbols in the even and
> odd sets those could be randomized. Numbers used two dice with 2
> subtracted from total and a 2 rolled with the dice returned a 0. Slow and
> necessary to write worksheet down as dice rolling proceeded and password
> needed writing down on completion. Since I do most of my writing in
> braille I have a good encryption system I can encrypt further by using the
> old English braille instead of the American braille. American braille has
> dot arrangement 123 down left side of cell for reading and 4 5 6 down
> right side of cell for reading. English braille has 1 3 5 down the left
> side and 2 4 6 down the right side of the cell for reading. Those are dot
> number arrangements. Braille readers on this list I expect maybe only one
> other will understand what I just wrote.
>
>
> -- Jude <jdashiel at panix dot com> "There are four boxes to be used in
> defense of liberty: soap, ballot, jury, and ammo. Please use in that
> order." Ed Howdershelt 1940.

It is interesting what people can come up with.  Thing is, if one uses a
true random generated password, they are hard to crack but also hard to
remember.  I try to come up with something that will be hard to crack
but easy for me to remember.  Thing is, I do have a few passwords to
keep up with.  I recently changed my root password.  I plan to change my
user password soon.  Then I have the password for Bitwarden.  Then I
have the password for the NAS, three external hard drives with different
passwords for each etc.  That's a lot to remember.  To be honest, it's
getting to be a bit much.  Associating one password to one item is also
difficult.  Unless one leaves clues.  Thing is, those clues reveal
things as well. 

For websites, I really like Bitwarden.  I remember one password and it
can generate passwords for all the websites I use.  The passwords it
generates are pretty random.  For sites that don't allow symbols, I can
turn that off.  The big point, I only remember one password.  Thing is,
on one hand I need help remembering all these passwords.  On the other
hand, that is a risk itself. 

This reminds me of a tennis ball.  It just goes back and forth. 

Dale

:-)  :-)

> On Tue, 19 Sep 2023, Michael wrote:
>
>> On Tuesday, 19 September 2023 06:36:13 BST Dale wrote:
>>> Howdy,
>>>
>>> As some know, I encrypt a lot of stuff here. I use passwords that I can
>>> recall but no one could ever guess. I don't use things that someone may
>>> figure out like pet's name or anything like that. I use a couple sites
>>> to see just how good my passwords are. I try to get into the millions
>>> of years at least. I have a couple that it claims is in the trillions
>>> of years to crack. I've read some things not to use like pet names and
>>> such. I've also read that one should use upper and lower case letters,
>>> symbols and such and I do that, especially on my stuff I never want to
>>> be cracked. Some stuff, when I'm dead, it's gone.
>> As/when quantum computers development progresses, many/some passwords and
>> hashes will be cracked/brute forced (RSA encryption springs to mind). It is
>> best if you can think of any password as keeping your door and windows locked.
>> They will stop most opportunistic attempts, but not anyone who is determined
>> to break in. It is unlikely your passwords will stop state actors. A strong
>> password, like a strong door lock, buys you time. Hence the general
>> recommendation to change your passwords frequently.
>>
>>
>>> In the real world tho, how do people reading this make passwords that no
>>> one could ever guess?
>> You can use gpg, or openssl, or app-admin/apg, or app-admin/pwgen, to generate
>> random enough strings to use as passwords. They will be difficult to guess,
>> but will be VERY difficult to remember. You'll have to store them offline
>> and/or protect them in turn with some master passphrase you can remember.
>>
>> As an example, you could choose characters/strings from the output stored in
>> file.txt, when you run:
>>
>> < /dev/random tr -dc "[:space:][:print:]" | head -c500 > file.txt
>>
>>
>>> I use Bitwarden to handle website passwords and
>>> it does a good job. I make up my own tho when encrypting drives. I'm
>>> not sure I can really use Bitwarden for that given it is a command line
>>> thing, well, in a script in my case. I doubt anyone would ever guess
>>> any of my passwords but how do people reading this do theirs? Just how
>>> far do you really go to make it secure? Obviously you shouldn't give up
>>> much detail but just some general ideas. Maybe even a example or two of
>>> a fake password, just something that you would come up with and how.
>>>
>>> This is the two sites I use.
>>>
>>>
>>> https://www.passwordmonster.com/
>>>
>>> https://www.security.org/how-secure-is-my-password/
>>>
>>>
>>> I have a password in the first one that shows this:
>>>
>>>
>>> It would take a computer about 63 thousand years to crack your password
>>>
>>>
>>> Second one says this.
>>>
>>> It would take a computer about 5 million years to crack your password
>>>
>>> Exact same password in both. Why such a large range to crack?
>> I don't know why these guys come up with different years-equivalent strength,
>> but I tend to treat such websites as suspicious. They are more likely to act
>> as a honeypot to *record* your passwords, than provide you with truly
>> meaningful information. I suppose you could use them to test an example of a
>> password you would never use thereafter, but even this could reveal some
>> underlying pattern in how you structure your passwords.
>>
>>
>>> I tend
>>> to use the first site to create a password. Then I test it in the
>>> second site to sort of confirm it. If both say a long time, then I got
>>> a fairly good one depending on what I'm protecting. Still, why such a
>>> difference? One reason I use the first site, I can make it show the
>>> password. The second site doesn't do that so editing it to improve
>>> things is harder since you can't see it. The first site makes that easy
>>> and gives me a idea of whether I'm on the right track. Second site
>>> confirms it. I did contact the second site and ask for a button to show
>>> the password. After all, no one is here but me. My windows are covered.
>>>
>>> Also, I use cryptsetup luksFormat -s 512 ... to encrypt things. Is
>>> that 512 a good number? Can it be something different? I'd think since
>>> it is needed as a option, it can have different values and encrypt
>>> stronger or weaker. Is that the case? I've tried to find out but it
>>> seems everyone uses 512. If that is the only value, why make it a
>>> option? I figure it can have other values but how does that work?
>> The size of key options depend on the block cipher. A larger key size tends
>> to be stronger, but its processing slower. Embedded devices without hardware
>> accelerated crypto could struggle with larger key sizes.
>>
>>
>>> Heck, a link to some good info on that would be good. :-)
>> https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md
>>
>> https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf
>>
>> https://wiki.archlinux.org/title/Data-at-rest_encryption
>>
>

Michael wrote:
> On Tuesday, 19 September 2023 12:13:40 BST Dale wrote:
>> Hmmmm,
>>
>> For some reason, I didn't get Michael's email. I see him being quoted
>> but don't have his original. I wonder what is up with that. O-o
> Assuming you will receive this message, have a look here:
>
> https://marc.info/?l=gentoo-user&m=169511184714476&w=2
>
>
>> Rich Freeman wrote:
>>> On Tue, Sep 19, 2023 at 4:26?AM Michael <confabulate@kintzios.com> wrote:
>>>> On Tuesday, 19 September 2023 06:36:13 BST Dale wrote:
>>>>> Howdy,
>>>> A strong
>>>> password, like a strong door lock, buys you time. Hence the general
>>>> recommendation to change your passwords frequently.
>>> While that can help on websites, it is of no use for full disk
>>> encryption passwords - at least not without jumping through some big
>>> hoops.
>>>
>>> In order to crack your LUKS password somebody obviously needs to be
>>> able to read the encrypted contents of your disk. They cannot begin
>>> cracking it until they have a copy of the LUKS headers. However, once
>>> they do have it, they can make a copy and crack it at their leisure.
>>> If they manage to crack it, then it will give them the volume key. At
>>> that point if they were able to make a full copy of your disk they can
>>> read whatever was on it at the time. If they can make a fresh copy of
>>> your disk then changing the passphrase will not change the volume key,
>>> and so they'll be able to read what is currently on your disk.
>>>
>>> Changing the volume key would defeat this, but requires running
>>> cryptsetup-reencrypt which will take considerable time/CPU, though it
>>> sounds like it can be done online.
>> Let's jump into a hypothetical here. Let's say I'm a nasty terrorist or
>> some other really evil dude. Let's say I have passwords are that really
>> good. Let's say around 20 characters and a really nice mix of
>> characters. If some gov't agency got my hard drive, how long would it
>> take for them to crack it?
> A couple of minutes?
>
> https://xkcd.com/538/
>
> :-)


I did get this one.  I also got the other message, I think at the same
time.  It sure did arrive late tho.  I have mine set up to view as
threads.  This thread looked odd until it got the previous message. 
Must have got hung up somewhere.  Maybe a server somewhere had to reboot
and it took a while.  ROFL 

I like the cartoon.  In some countries, that would likely be a first
option.  :/

Dale

:-)  :-) 

On 2023-09-20, Dale <rdalek1967@gmail.com> wrote:

> For websites, I really like Bitwarden.  I remember one password and it
> can generate passwords for all the websites I use.  The passwords it
> generates are pretty random.  For sites that don't allow symbols, I can
> turn that off.  The big point, I only remember one password.  Thing is,
> on one hand I need help remembering all these passwords.  On the other
> hand, that is a risk itself.

I second the recommendation of Bitwarden. I used to use Lastpass but
they discontinued their free version, and the entry-level price was
just too high. I was so impressed with Bitwarden's support that I did
end up subsribing to their lowest-level paid service even though I
don't really need any of the extras that gets me. It's also nice to
know that I can set up my own Bitwarden server if I want to.

If you're using Bitwarden's cloudy storage, don't forget to back up
your password database locally too. I always back it up in human
readable format and then encrypt it using openssl command-line
methods. You don't want to have to depend on either Bitwarden's
servers or the Bitwarden app to retreive your passwords.

--
Grant

Michael wrote:
> On Tuesday, 19 September 2023 06:36:13 BST Dale wrote:
>
>> Heck, a link to some good info on that would be good. :-)
> https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md
>
> https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf
>
> https://wiki.archlinux.org/title/Data-at-rest_encryption

Oops.  Should have sent this in other message. 

Interesting links.  Some of the info I'm clueless.  I don't know some of
the terms and what they mean.  Some of it I get tho.  Basically, despite
people wanting to encrypt to protect data, some powerful entities can
still crack it no matter how good the password or phrase is.  It seems
encryption done 'on the fly' I think is the phrase they use is just very
hard to do without some serious CPU power or other tools.  Am I getting it?

I have a question tho.  Can a person use a password/pass phrase that is
like this:  'This is a stupid pass phrase.'   Does it accept that even
with spaces?  I know file names can have spaces for a long while now but
way back, you couldn't do that easily.  One had to use dashes or
underscores.  Uses spaces could open a few options. 

Dale

:-)  :-) 

Grant Edwards wrote:
> On 2023-09-20, Dale <rdalek1967@gmail.com> wrote:
>
>> For websites, I really like Bitwarden.  I remember one password and it
>> can generate passwords for all the websites I use.  The passwords it
>> generates are pretty random.  For sites that don't allow symbols, I can
>> turn that off.  The big point, I only remember one password.  Thing is,
>> on one hand I need help remembering all these passwords.  On the other
>> hand, that is a risk itself.
> I second the recommendation of Bitwarden. I used to use Lastpass but
> they discontinued their free version, and the entry-level price was
> just too high. I was so impressed with Bitwarden's support that I did
> end up subsribing to their lowest-level paid service even though I
> don't really need any of the extras that gets me. It's also nice to
> know that I can set up my own Bitwarden server if I want to.
>
> If you're using Bitwarden's cloudy storage, don't forget to back up
> your password database locally too. I always back it up in human
> readable format and then encrypt it using openssl command-line
> methods. You don't want to have to depend on either Bitwarden's
> servers or the Bitwarden app to retreive your passwords.
>
> --
> Grant
>

Usually, once a year I change my major passwords, bank, credit card,
ebay, Paypal, Amazon and such.  I have a folder thingy that I store
those in to make sure I don't forget to change something important. 
Anyway, when I do that and use the new passwords successfully, I make a
backup copy and on my rig, I can encrypt it with a right click.  I then
shred the original.  While I think Bitwarden will be around and they
will work fine, one never knows. 

I'm thinking of making a one time donation to Bitwarden.  Just to help
them out.  I can't do much but I can do that.  I used Lastpass until
they switched too. I actually imported my passwords from one to the
other.  It seems to work the same way to me. 

I still use Lastpass in Seamonkey.  Bitwarden doesn't have a plugin for
Seamonkey that I've found.  Lastpass hasn't been updated in ages
either.  Once Firefox did their major changes a few years ago, a lot of
old plugins are no longer maintained.  Seamonkey needs to catch up or it
is going to die. 

Dale

:-)  :-) 

Am 20.09.23 um 04:41 schrieb Dale:
> It is interesting what people can come up with.  Thing is, if one uses a
> true random generated password, they are hard to crack but also hard to
> remember.  I try to come up with something that will be hard to crack
> but easy for me to remember.

If someone has a child one can always frame the first language test and
put it at the wall in the office together with some family photos. Those
spelling errors might not be random but for all practical use they are
not predictable. One can always look it up. Just remember the line of
the password. This is hidden in plain sight.

On Wednesday, 20 September 2023 05:19:18 BST Dale wrote:
> Michael wrote:
> > On Tuesday, 19 September 2023 06:36:13 BST Dale wrote:
> >> Heck, a link to some good info on that would be good. :-)
> >
> > https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md
> >
> > https://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-forma
> > t.pdf
> >
> > https://wiki.archlinux.org/title/Data-at-rest_encryption
>
> Oops. Should have sent this in other message.
>
> Interesting links. Some of the info I'm clueless. I don't know some of
> the terms and what they mean. Some of it I get tho. Basically, despite
> people wanting to encrypt to protect data, some powerful entities can
> still crack it no matter how good the password or phrase is. It seems
> encryption done 'on the fly' I think is the phrase they use is just very
> hard to do without some serious CPU power or other tools. Am I getting it?

Security can be compromised because people use easy to guess passwords, or by
using side-channel attack methods. As Snowden mentioned, if you rely on a low
entropy device, e.g. a mobile phone, on which the base frequency can also be
compromised, then that could be the weakest link for an attack. Not to
mention keyloggers and various MITM attacks, which on phones at least are
rumoured to be the way to compromise a device. Cracking algos and ciphers is
computationally more expensive, performed offline and probably the last
resort. That said, if you assume state actors are at least 10 years ahead of
you in terms of technological solutions and resources, you'd be at the right
ballpark.


> I have a question tho. Can a person use a password/pass phrase that is
> like this: 'This is a stupid pass phrase.' Does it accept that even
> with spaces? I know file names can have spaces for a long while now but
> way back, you couldn't do that easily. One had to use dashes or
> underscores. Uses spaces could open a few options.

Generally speaking space characters are a poor choice for randomness. I
recall seeing some documentary about the Enigma machine used by the German
military during the 2nd WW. To minimise attempts to brute force the
ciphertext, they started by identifying which letter(s) were most frequently
used in the German language - e.g. the letter "e", then the second most
frequent letter and so on. This statistical analysis approach in combination
with likely message content reduced the number of guesses. In principle, a
repeated space character in your passphrase could help reduce the
computational burden of an offline brute force attack, by e.g. helping an
attacker to identify the number of individual words in a passphrase. All
these passphrases and whatever other private info you pasted into different
websites could also be harvested and used to determine some statistical
pattern in your selected passphrases. However, different ciphers and stronger
keys guard against easy cracking by brute force.

Am Tue, Sep 19, 2023 at 12:36:13AM -0500 schrieb Dale:
>In the real world tho, how do people reading this make passwords that no
>one could ever guess?  I use Bitwarden to handle website passwords and
>it does a good job.  I make up my own tho when encrypting drives.  I'm
>not sure I can really use Bitwarden for that given it is a command line
>thing, well, in a script in my case.  I doubt anyone would ever guess
>any of my passwords but how do people reading this do theirs?  Just how
>far do you really go to make it secure?  Obviously you shouldn't give up
>much detail but just some general ideas.  Maybe even a example or two of
>a fake password, just something that you would come up with and how. 

For storing passwords, I use app-admin/pass.

For choosing passphrases, I write sentences. I know having space character at a
predictable frequence in the passphrase makes it easier to find out, but using
phrases makes it easier to come up with very long passphrases (which, I
believe, balances the space thing, though I’m no crypto expert), which are also
easy to remember.

Hoël

On 9/20/23 12:18, Hoël Bézier wrote:

> Am Tue, Sep 19, 2023 at 12:36:13AM -0500 schrieb Dale:
>> In the real world tho, how do people reading this make passwords that no
>> one could ever guess?  I use Bitwarden to handle website passwords and
>> it does a good job.  I make up my own tho when encrypting drives.  I'm
>> not sure I can really use Bitwarden for that given it is a command line
>> thing, well, in a script in my case.  I doubt anyone would ever guess
>> any of my passwords but how do people reading this do theirs? Just how
>> far do you really go to make it secure?  Obviously you shouldn't give up
>> much detail but just some general ideas.  Maybe even a example or two of
>> a fake password, just something that you would come up with and how.
>
> For storing passwords, I use app-admin/pass.
>
> For choosing passphrases, I write sentences. I know having space
> character at a predictable frequence in the passphrase makes it easier
> to find out, but using phrases makes it easier to come up with very
> long passphrases (which, I believe, balances the space thing, though
> I’m no crypto expert), which are also easy to remember.
I don't think anyone has yet mentioned using the first (or last or
second) letter of each word in the first (or last) sentence of a
favorite book or poem or song, possibly modifying with some upper case
and sprinkling in digits and special characters.

Another possibility is to write down encrypted passwords and don't
disclose encryption technique. The rot13 is worthless.


-- Jude <jdashiel at panix dot com> "There are four boxes to be used in
defense of liberty: soap, ballot, jury, and ammo. Please use in that
order." Ed Howdershelt 1940.

On Wed, 20 Sep 2023, Hoël Bézier wrote:

> Am Tue, Sep 19, 2023 at 12:36:13AM -0500 schrieb Dale:
> >In the real world tho, how do people reading this make passwords that no
> >one could ever guess?  I use Bitwarden to handle website passwords and
> >it does a good job.  I make up my own tho when encrypting drives.  I'm
> >not sure I can really use Bitwarden for that given it is a command line
> >thing, well, in a script in my case.  I doubt anyone would ever guess
> >any of my passwords but how do people reading this do theirs?  Just how
> >far do you really go to make it secure?  Obviously you shouldn't give up
> >much detail but just some general ideas.  Maybe even a example or two of
> >a fake password, just something that you would come up with and how. 
>
> For storing passwords, I use app-admin/pass.
>
> For choosing passphrases, I write sentences. I know having space character at
> a predictable frequence in the passphrase makes it easier to find out, but
> using phrases makes it easier to come up with very long passphrases (which, I
> believe, balances the space thing, though I’m no crypto expert), which are
> also easy to remember.
>
> Hoël
>
>

Am Wed, Sep 20, 2023 at 01:28:09PM +0100 schrieb Michael:

> > I have a question tho. Can a person use a password/pass phrase that is
> > like this: 'This is a stupid pass phrase.' Does it accept that even
> > with spaces? I know file names can have spaces for a long while now but
> > way back, you couldn't do that easily. One had to use dashes or
> > underscores.

Sure, why not? It’s a string like any other. No spaces in filenames where a
restriction of (now outdated) file systems. And I guess developers didn’t
account for them back in those days (and later out of habit). When I used
DOS, of course I adhered to the 8.3 rule. But ever since I started using
Windows, XP at the latest (2001), I wholly started using spaces everywhere
and never looked back. The programs that had problems with spaces were few
and script authors should just adhere to best practices and put filename
variables in quotes, so they can work with spaces. The only nuissance they
pose for me is it may make tab completion cumbersome sometimes.

PS.: I find underscores ugly. :D

> Generally speaking space characters are a poor choice for randomness. I
> recall seeing some documentary about the Enigma machine used by the German
> military during the 2nd WW. To minimise attempts to brute force the
> ciphertext, they started by identifying which letter(s) were most frequently
> used in the German language - e.g. the letter "e", then the second most
> frequent letter and so on. This statistical analysis approach in combination
> with likely message content reduced the number of guesses.

Here you speak of the payload, not the passphrase, which is the encyption
key. The key was rotated after each character and the initial key setting (the
tumbler position) was distributed in secret code books.

> In principle, a repeated space character in your passphrase could help
> reduce the computational burden of an offline brute force attack, by e.g.
> helping an attacker to identify the number of individual words in a
> passphrase.

Due to the rotation, the Enigma encoded each subsequent letter differently,
even if the same one repeated, which was (one of) the big strengths of the
Enigma cipher. The flaws were elsewhere, for example that a character could
never be encrypted onto itself due to the internal wiring and certain
message parts were always the same, like message headers and greetings.

For LUKS, having spaces in your passphrase (or their frequency) has no
influence on the ciphertext, since the passphrase itself is not used for
encryption. The passphrase only unlocks the actual key, which is then used
for encryption. It comes down to whether the passphrase can easily be
guessed by dictionary attacks. So if you write normal sentences with
correctly written words, they might be easy to crack. I don’t expect it
makes a big difference to the brute force software whether you use spaces or
not.

--
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

Suicide is the most honest form of self-criticism.

Am Tue, Sep 19, 2023 at 11:49:24PM -0500 schrieb Dale:

> Anyway, when I do that and use the new passwords successfully, I make a
> backup copy and on my rig, I can encrypt it with a right click.  I then
> shred the original.

Just on a sidenote, once you’re on an SSD, shredding has no use and is
actually detrimental.

--
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

On Mondays I feel like Robinson -- I’m waiting for Friday.

On Wed, Sep 20, 2023 at 4:22?PM Frank Steinmetzger <Warp_7@gmx.de> wrote:
>
> Am Tue, Sep 19, 2023 at 11:49:24PM -0500 schrieb Dale:
>
> > Anyway, when I do that and use the new passwords successfully, I make a
> > backup copy and on my rig, I can encrypt it with a right click. I then
> > shred the original.
>
> Just on a sidenote, once you’re on an SSD, shredding has no use and is
> actually detrimental.
>

I'm not sure I'd go quite that far, but it certainly isn't as effective.

No way to be certain how well it works, but it is certainly worth
doing an ATA Secure Erase command on the drive. A good SSD should
implement that in a way that ensures all the data is actually
unretrievable (probably by implementing full disk encryption and
erasing the key). Of course, there is no way to tell if the drive was
implemented well.

Full-disk encryption at the OS level is of course the best way to
protect against recovery of data on a discarded disk.

--
Rich

Am Wed, Sep 20, 2023 at 04:51:36PM -0400 schrieb Rich Freeman:

> > > Anyway, when I do that and use the new passwords successfully, I make a
> > > backup copy and on my rig, I can encrypt it with a right click. I then
> > > shred the original.
> >
> > Just on a sidenote, once you’re on an SSD, shredding has no use and is
> > actually detrimental.
> >
>
> I'm not sure I'd go quite that far, but it certainly isn't as effective.
>
> No way to be certain how well it works, but it is certainly worth
> doing an ATA Secure Erase command on the drive. A good SSD should
> implement that in a way that ensures all the data is actually
> unretrievable (probably by implementing full disk encryption and
> erasing the key). Of course, there is no way to tell if the drive was
> implemented well.

Uhm, Dale was talking of a single file, not an entire disk. ;-)

--
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.

do something for your image -- let yourself be seen with me.