I am a little confused about creating encryption keys. How exactly
does one create a 128, 512 or 1024 bit key? If I use an encryption
software, does the encryption key mean the password? If so, is it
enough if I create a 128/8=16 char password or even 512/8=64 char
password?
On 2007-07-10, rohanm79@gmail.com
> I am a little confused about creating encryption keys. How exactly
> does one create a 128, 512 or 1024 bit key? If I use an encryption
> software, does the encryption key mean the password? If so, is it
> enough if I create a 128/8=16 char password or even 512/8=64 char
> password?
How to specify key length depends on what kind of software you're
talking about. Usually it's set as some sort of command-line
argument or in a config file, or it may be prompted for
interactively. Consult the man page for details.
Dealing with public key encryption systems, the actual encryption
key generally has nothing to do with the password which you may or
may not be asked to provide. When you create a keypair with, e.g.,
GPG or OpenSSL, the key parameters themselves are pseudorandomly (or
randomly, depending on your hardware) generated in the program. The
password is only used as the basis for a /symmetric/ key with which
to protect the generated private encryption key; this is done to
make it more difficult for an attacker to obtain your private key,
should the file it is contained within fall into the wrong hands.
Let us know which particular software you're dealing with if that
didn't completely answer your question.
Mark
--
Mark Shroyer
http://markshroyer.com/
On Jul 10, 12:22 pm, Mark Shroyer
> On 2007-07-10, rohan...@gmail.com
>
> > I am a little confused about creating encryption keys. How exactly
> > does one create a 128, 512 or 1024 bit key? If I use an encryption
> > software, does the encryption key mean the password? If so, is it
> > enough if I create a 128/8=16 char password or even 512/8=64 char
> > password?
>
> How to specify key length depends on what kind of software you're
> talking about. Usually it's set as some sort of command-line
> argument or in a config file, or it may be prompted for
> interactively. Consult the man page for details.
>
> Dealing with public key encryption systems, the actual encryption
> key generally has nothing to do with the password which you may or
> may not be asked to provide. When you create a keypair with, e.g.,
> GPG or OpenSSL, the key parameters themselves are pseudorandomly (or
> randomly, depending on your hardware) generated in the program. The
> password is only used as the basis for a /symmetric/ key with which
> to protect the generated private encryption key; this is done to
> make it more difficult for an attacker to obtain your private key,
> should the file it is contained within fall into the wrong hands.
>
> Let us know which particular software you're dealing with if that
> didn't completely answer your question.
>
> Mark
>
> --
> Mark Shroyerhttp://markshroyer.com/
Thanks Mark. Basically, I found some software that does AES and
Blowfish encryption on text and other files. I know that AES uses 256
bit keys for encryption and it asked me to give a password. I wasnt
sure if I needed to give a 32 char password because it did the
encryption even with smaller passwords. So how do I know what was the
key used for encryption? And how do I communicate that key to the
recipient of the encrypted file?
On 2007-07-10, rohanm79@gmail.com
> On Jul 10, 12:22 pm, Mark Shroyer
>> On 2007-07-10, rohan...@gmail.com
>>
>> > I am a little confused about creating encryption keys. How exactly
>> > does one create a 128, 512 or 1024 bit key? If I use an encryption
>> > software, does the encryption key mean the password? If so, is it
>> > enough if I create a 128/8=16 char password or even 512/8=64 char
>> > password?
>>
>> How to specify key length depends on what kind of software you're
>> talking about. Usually it's set as some sort of command-line
>> argument or in a config file, or it may be prompted for
>> interactively. Consult the man page for details.
>>
>> Dealing with public key encryption systems, the actual encryption
>> key generally has nothing to do with the password which you may or
>> may not be asked to provide. When you create a keypair with, e.g.,
>> GPG or OpenSSL, the key parameters themselves are pseudorandomly (or
>> randomly, depending on your hardware) generated in the program. The
>> password is only used as the basis for a /symmetric/ key with which
>> to protect the generated private encryption key; this is done to
>> make it more difficult for an attacker to obtain your private key,
>> should the file it is contained within fall into the wrong hands.
>>
>> Let us know which particular software you're dealing with if that
>> didn't completely answer your question.
>
> Thanks Mark. Basically, I found some software that does AES and
> Blowfish encryption on text and other files. I know that AES uses 256
> bit keys for encryption and it asked me to give a password. I wasnt
> sure if I needed to give a 32 char password because it did the
> encryption even with smaller passwords. So how do I know what was the
> key used for encryption? And how do I communicate that key to the
> recipient of the encrypted file?
No, you shouldn't need to enter a 32-character password (although I
can't say for sure because you still haven't specified what software
you're talking about :) ). What usually happens is that the 256-bit
symmetric key is generated as some hash of whatever password you
provide. The longer and more random the password (until you get
past 32 random ASCII characters, anyway), the more entropy in your
256-bit AES key and therefore the more theoretically secure it is --
but in practice a dozen or so characters should be all the entropy
you need, depending on the quality of your software's hash algorithm
and how sensitive your data is.
As for communicating the encrypted data to somebody else, you'll
both really want to be using the same encryption software. There's
no de-facto standard algorithm for converting passwords into
symmetric encryption keys (as far as I know -- maybe someone here
knows better?), so different software might interpret the same
password as signifying different keys. You probably won't be able
to determine the actual AES key that your software used unless
you're willing to dig into its source code.
On top of that, the output of your encryption software may not be
strictly an AES-encrypted copy of the original data: it could
contain some header information or be formatted in some particular
way, and will hopefully have been compressed prior to encryption for
added security; different encryption software is incompatible also
in these respects. So use the same software as your recipient, and
(physically, not electronically -- but you probably knew that
already) provide him or her your encryption key in the form of the
password.
Out of curiosity, why are you interested in obtaining the raw AES
key?
--
Mark Shroyer
http://markshroyer.com/
Mark Shroyer
> > Thanks Mark. Basically, I found some software that does AES and
> > Blowfish encryption on text and other files. I know that AES uses
> > 256 bit keys for encryption and it asked me to give a password. I
> > wasnt sure if I needed to give a 32 char password because it did the
> > encryption even with smaller passwords. So how do I know what was
> > the key used for encryption? And how do I communicate that key to
> > the recipient of the encrypted file?
>
> No, you shouldn't need to enter a 32-character password (although I
> can't say for sure because you still haven't specified what software
> you're talking about :) ). What usually happens is that the 256-bit
> symmetric key is generated as some hash of whatever password you
> provide. The longer and more random the password (until you get past
> 32 random ASCII characters, anyway), the more entropy in your 256-bit
> AES key and therefore the more theoretically secure it is -- but in
> practice a dozen or so characters should be all the entropy you need,
> depending on the quality of your software's hash algorithm and how
> sensitive your data is.
This is imprecise. 32 characters will by far not be enough for the
password to have 256 bits of entropy. Remember that users only use a
subset of all possible characters (and they shouldn't use them all,
because of localization issues).
In most cases one character of the password will have slightly less than
seven bits of entropy, because you don't type eight bit characters, and
you also don't type control characters.
> There's no de-facto standard algorithm for converting passwords into
> symmetric encryption keys (as far as I know -- maybe someone here
> knows better?), [...]
There is: PBKDF2, for example.
> [...] so different software might interpret the same password as
> signifying different keys. You probably won't be able to determine
> the actual AES key that your software used unless you're willing to
> dig into its source code.
If they both use the same protocol together with the same specification,
then most likely they will be compatible.
Regards,
Ertugrul Söylemez.
--=20
Security is the one concept, which makes things in your life stay as
they are. Otto is a man, who is afraid of changes in his life; so
naturally he does not employ security.
On 2007-07-11, Ertugrul Soeylemez
> Mark Shroyer
>> No, you shouldn't need to enter a 32-character password (although I
>> can't say for sure because you still haven't specified what software
>> you're talking about :) ). What usually happens is that the 256-bit
>> symmetric key is generated as some hash of whatever password you
>> provide. The longer and more random the password (until you get past
>> 32 random ASCII characters, anyway), the more entropy in your 256-bit
>> AES key and therefore the more theoretically secure it is -- but in
>> practice a dozen or so characters should be all the entropy you need,
>> depending on the quality of your software's hash algorithm and how
>> sensitive your data is.
>
> This is imprecise. 32 characters will by far not be enough for the
> password to have 256 bits of entropy. Remember that users only use a
> subset of all possible characters (and they shouldn't use them all,
> because of localization issues).
>
> In most cases one character of the password will have slightly less than
> seven bits of entropy, because you don't type eight bit characters, and
> you also don't type control characters.
Yes, you're right of course; by "32 random ASCII characters" I
actually meant 32 characters from all possible ASCII values 0-127,
printable or not. Just thought I'd leave out the discussion of
practical specifics in the interest of brevity.
>> There's no de-facto standard algorithm for converting passwords into
>> symmetric encryption keys (as far as I know -- maybe someone here
>> knows better?), [...]
>
> There is: PBKDF2, for example.
Thanks, I hadn't realized there is an IETF standard for this. Even
so, because AES software doesn't inherently use PBKDF2, the original
poster cannot rely on his program to be password-compatible with
whatever arbitrary decryption package his recipient may decide to
use.
>> [...] so different software might interpret the same password as
>> signifying different keys. You probably won't be able to determine
>> the actual AES key that your software used unless you're willing to
>> dig into its source code.
>
> If they both use the same protocol together with the same specification,
> then most likely they will be compatible.
--
Mark Shroyer
http://markshroyer.com/
Mark Shroyer
> > This is imprecise. 32 characters will by far not be enough for the
> > password to have 256 bits of entropy. Remember that users only use
> > a subset of all possible characters (and they shouldn't use them
> > all, because of localization issues).
> >
> > In most cases one character of the password will have slightly less
> > than seven bits of entropy, because you don't type eight bit
> > characters, and you also don't type control characters.
>
> Yes, you're right of course; by "32 random ASCII characters" I
> actually meant 32 characters from all possible ASCII values 0-127,
> printable or not. Just thought I'd leave out the discussion of
> practical specifics in the interest of brevity.
The set of printable ASCII characters is a less-than-seven bit character
set, as you see directly from the fact that it contains only 95
characters (32..126). You need 39 completely random characters of this
kind to get (slightly more than) 256 bits of entropy.
You cannot include the non-printable subset, because there is no easy
and portable way to type them, especially in GUIs. Though, even
including the non-printables, you will still need 37 random characters
for 256 bits of entropy.
Regards,
Ertugrul Söylemez.
--=20
Security is the one concept, which makes things in your life stay as
they are. Otto is a man, who is afraid of changes in his life; so
naturally he does not employ security.
On 2007-07-11, Ertugrul Soeylemez
> Mark Shroyer
>
>> > This is imprecise. 32 characters will by far not be enough for the
>> > password to have 256 bits of entropy. Remember that users only use
>> > a subset of all possible characters (and they shouldn't use them
>> > all, because of localization issues).
>> >
>> > In most cases one character of the password will have slightly less
>> > than seven bits of entropy, because you don't type eight bit
>> > characters, and you also don't type control characters.
>>
>> Yes, you're right of course; by "32 random ASCII characters" I
>> actually meant 32 characters from all possible ASCII values 0-127,
>> printable or not. Just thought I'd leave out the discussion of
>> practical specifics in the interest of brevity.
>
> The set of printable ASCII characters is a less-than-seven bit character
> set, as you see directly from the fact that it contains only 95
> characters (32..126). You need 39 completely random characters of this
> kind to get (slightly more than) 256 bits of entropy.
>
> You cannot include the non-printable subset, because there is no easy
> and portable way to type them, especially in GUIs. Though, even
> including the non-printables, you will still need 37 random characters
> for 256 bits of entropy.
And that's what I meant by saying "past 32 random ASCII characters"
instead of "to 32 random ASCII characters". Again, that's all
correct -- it just wasn't relevant in the interest of succinctly
answering the original poster's question.
--
Mark Shroyer
http://markshroyer.com/
On Tue, 10 Jul 2007 09:15:03 +0000 (UTC), Mark Shroyer wrote:
> No, you shouldn't need to enter a 32-character password (although I
> can't say for sure because you still haven't specified what software
> you're talking about :) ). What usually happens is that the 256-bit
> symmetric key is generated as some hash of whatever password you
> provide. The longer and more random the password (until you get
> past 32 random ASCII characters, anyway), the more entropy in your
> 256-bit AES key and therefore the more theoretically secure it is --
> but in practice a dozen or so characters should be all the entropy
> you need, depending on the quality of your software's hash algorithm
> and how sensitive your data is.
Mark, nice job with the answers, noobs often get handed their asses
here.
Is it fair to say that if you used a passphrase such as:
6:Q?-jiF
Then repeated it to make a 16 character passphrase, under attack to
break, that you haven't gained much entropy or protection? My thinking
is that a powerful adversary would have a passphrase breaking program
that would constantly search for replication.
On 2007-07-11, Ari
> On Tue, 10 Jul 2007 09:15:03 +0000 (UTC), Mark Shroyer wrote:
>
>> No, you shouldn't need to enter a 32-character password (although I
>> can't say for sure because you still haven't specified what software
>> you're talking about :) ). What usually happens is that the 256-bit
>> symmetric key is generated as some hash of whatever password you
>> provide. The longer and more random the password (until you get
>> past 32 random ASCII characters, anyway), the more entropy in your
>> 256-bit AES key and therefore the more theoretically secure it is --
>> but in practice a dozen or so characters should be all the entropy
>> you need, depending on the quality of your software's hash algorithm
>> and how sensitive your data is.
>
> [...]
>
> Is it fair to say that if you used a passphrase such as:
>
> 6:Q?-jiF
>
> Then repeated it to make a 16 character passphrase, under attack to
> break, that you haven't gained much entropy or protection? My thinking
> is that a powerful adversary would have a passphrase breaking program
> that would constantly search for replication.
In my opinion, you're right -- you wouldn't gain much. I don't know
personally whether the best black hat brute-force software tries for
repetition in passwords, but it seems like a reasonable next angle
of approach should a dictionary attack fail.
So if you want double the strength in your password, generate twice
as many random characters. Sure it might be annoying to memorize,
but just think of it as an alternative to playing Nintendo's Brain
Age -- with the added benefit of securing your data :)
Mark
--
Mark Shroyer
http://markshroyer.com/
Ari
> Is it fair to say that if you used a passphrase such as:
>
> 6:Q?-jiF
>
> Then repeated it to make a 16 character passphrase, under attack to
> break, that you haven't gained much entropy or protection? My thinking
> is that a powerful adversary would have a passphrase breaking program
> that would constantly search for replication.
If the attacker does not know your password pattern (i.e. whether, where
and how often you repeat), then the new password will be more secure,
but not as secure as a random 16 character password (since the attacker
might try guessing against repetition patterns).
Regards,
Ertugrul Söylemez.
--=20
Security is the one concept, which makes things in your life stay as
they are. Otto is a man, who is afraid of changes in his life; so
naturally he does not employ security.
Mark Shroyer
> And that's what I meant by saying "past 32 random ASCII characters"
> instead of "to 32 random ASCII characters". Again, that's all correct
> -- it just wasn't relevant in the interest of succinctly answering the
> original poster's question.
"Past 38 random ASCII characters" would be correct. With 34 characters,
you don't get 256 bits of entropy, but only slightly more than 223 bits.
Regards,
Ertugrul Söylemez.
--=20
Security is the one concept, which makes things in your life stay as
they are. Otto is a man, who is afraid of changes in his life; so
naturally he does not employ security.
On Wed, 11 Jul 2007 19:57:50 +0000 (UTC), Mark Shroyer wrote:
> On 2007-07-11, Ari
>> On Tue, 10 Jul 2007 09:15:03 +0000 (UTC), Mark Shroyer wrote:
>>
>>> No, you shouldn't need to enter a 32-character password (although I
>>> can't say for sure because you still haven't specified what software
>>> you're talking about :) ). What usually happens is that the 256-bit
>>> symmetric key is generated as some hash of whatever password you
>>> provide. The longer and more random the password (until you get
>>> past 32 random ASCII characters, anyway), the more entropy in your
>>> 256-bit AES key and therefore the more theoretically secure it is --
>>> but in practice a dozen or so characters should be all the entropy
>>> you need, depending on the quality of your software's hash algorithm
>>> and how sensitive your data is.
>>
>> [...]
>>
>> Is it fair to say that if you used a passphrase such as:
>>
>> 6:Q?-jiF
>>
>> Then repeated it to make a 16 character passphrase, under attack to
>> break, that you haven't gained much entropy or protection? My thinking
>> is that a powerful adversary would have a passphrase breaking program
>> that would constantly search for replication.
>
> In my opinion, you're right -- you wouldn't gain much. I don't know
> personally whether the best black hat brute-force software tries for
> repetition in passwords, but it seems like a reasonable next angle
> of approach should a dictionary attack fail.
>
> So if you want double the strength in your password, generate twice
> as many random characters. Sure it might be annoying to memorize,
> but just think of it as an alternative to playing Nintendo's Brain
> Age -- with the added benefit of securing your data :)
>
> Mark
I have three 8 character rangen passwords and until I read my own words,
I never thought of combining them into one. Jeez.
> Ari
>
>> Is it fair to say that if you used a passphrase such as:
>>
>> 6:Q?-jiF
>>
>> Then repeated it to make a 16 character passphrase, under attack to
>> break, that you haven't gained much entropy or protection? My thinking
>> is that a powerful adversary would have a passphrase breaking program
>> that would constantly search for replication.
On Thu, 12 Jul 2007 04:39:08 +0200, Ertugrul Soeylemez wrote:
> If the attacker does not know your password pattern (i.e. whether, where
> and how often you repeat), then the new password will be more secure,
> but not as secure as a random 16 character password (since the attacker
> might try guessing against repetition patterns).
>
> Regards,
> Ertugrul Söylemez.
Yes, and this is the crux of the question, I suppose. Is checking for
repetition a common approach in password unveiling. It would seem
logical that it is since this would be a simple way to more easily
remember 16+ character passwords. Maybe not, maybe that's too tough of
an algorithmic equation.
Ari
> > If the attacker does not know your password pattern (i.e. whether,
> > where and how often you repeat), then the new password will be more
> > secure, but not as secure as a random 16 character password (since
> > the attacker might try guessing against repetition patterns).
>
> Yes, and this is the crux of the question, I suppose. Is checking for
> repetition a common approach in password unveiling. It would seem
> logical that it is since this would be a simple way to more easily
> remember 16+ character passwords. Maybe not, maybe that's too tough of
> an algorithmic equation.
Maybe I would do this implicitly, by changing the order of passphrases
to match against. Considering that a rather small percentage of people
use repetition, I wouldn't do this explicitly.
Regards,
Ertugrul Söylemez.
--=20
Security is the one concept, which makes things in your life stay as
they are. Otto is a man, who is afraid of changes in his life; so
naturally he does not employ security.
On Sat, 14 Jul 2007 07:52:45 +0200, Ertugrul Soeylemez wrote:
>>> If the attacker does not know your password pattern (i.e. whether,
>>> where and how often you repeat), then the new password will be more
>>> secure, but not as secure as a random 16 character password (since
>>> the attacker might try guessing against repetition patterns).
>>
>> Yes, and this is the crux of the question, I suppose. Is checking for
>> repetition a common approach in password unveiling. It would seem
>> logical that it is since this would be a simple way to more easily
>> remember 16+ character passwords. Maybe not, maybe that's too tough of
>> an algorithmic equation.
>
> Maybe I would do this implicitly, by changing the order of passphrases
> to match against. Considering that a rather small percentage of people
> use repetition, I wouldn't do this explicitly.
>
> Regards,
> Ertugrul Söylemez.
I would think that repetition is more common than that.
Ari
> > Maybe I would do this implicitly, by changing the order of
> > passphrases to match against. Considering that a rather small
> > percentage of people use repetition, I wouldn't do this explicitly.
>
> I would think that repetition is more common than that.
Among passwords, which are trivial anyway, it's probably common, like
"byebye", "johnnyjohn" or "boy boy boy". You will agree that serious
passwords generally don't use repetition. Even if they do, the patterns
aren't quite as obvious.
Regards,
Ertugrul Söylemez.
--=20
Security is the one concept, which makes things in your life stay as
they are. Otto is a man, who is afraid of changes in his life; so
naturally he does not employ security.
On Mon, 16 Jul 2007 06:49:18 +0200, Ertugrul Soeylemez wrote:
>> I would think that repetition is more common than that.
>
> Among passwords, which are trivial anyway, it's probably common, like
> "byebye", "johnnyjohn" or "boy boy boy". You will agree that serious
> passwords generally don't use repetition. Even if they do, the patterns
> aren't quite as obvious.
>
> Regards,
> Ertugrul Söylemez.
Would you consider either of these serious passwords?
6:Q?-jiF6:Q?-jiF
6:Q?-jiFFij-?Q:6
Ari
> Would you consider either of these serious passwords?
>
> 6:Q?-jiF6:Q?-jiF
> 6:Q?-jiFFij-?Q:6
Not really. Probably they are impractical to break for a random
attacker, but it's still safer to use a completely random string without
repetition. Then it also doesn't have to be so long.
Regards,
Ertugrul Söylemez.
--=20
Security is the one concept, which makes things in your life stay as
they are. Otto is a man, who is afraid of changes in his life; so
naturally he does not employ security.
On Wed, 25 Jul 2007 08:29:10 +0200, Ertugrul Soeylemez wrote:
> Among passwords, which are trivial anyway, it's probably common, like
> "byebye", "johnnyjohn" or "boy boy boy". You will agree that serious
> passwords generally don't use repetition. Even if they do, the patterns
> aren't quite as obvious.
> Ari
>
>> Would you consider either of these serious passwords?
>>
>> 6:Q?-jiF6:Q?-jiF
>> 6:Q?-jiFFij-?Q:6
>
> Not really. Probably they are impractical to break for a random
> attacker, but it's still safer to use a completely random string without
> repetition. Then it also doesn't have to be so long.
>
> Regards,
> Ertugrul Söylemez.
I suppose this is the crux of my argument. On the order of practicality,
it is best to have the shortest possible password (easiest to remember).
You will need to have several (all eggs in one basket = no good). so the
shorter the better.
Unless the examples above, again rearranged so to be easily remembered
are, or combined into 32 character passwords...
Where is the point of best safety? One must assume a powerful adversary
to find that point. Or do we ever really know?
Ari
> > > Would you consider either of these serious passwords?
> > >
> > > 6:Q?-jiF6:Q?-jiF
> > > 6:Q?-jiFFij-?Q:6
> >
> > Not really. Probably they are impractical to break for a random
> > attacker, but it's still safer to use a completely random string
> > without repetition. Then it also doesn't have to be so long.
>
> I suppose this is the crux of my argument. On the order of
> practicality, it is best to have the shortest possible password
> (easiest to remember). You will need to have several (all eggs in one
> basket =3D no good). so the shorter the better.
>
> Unless the examples above, again rearranged so to be easily remembered
> are, or combined into 32 character passwords...
>
> Where is the point of best safety? One must assume a powerful
> adversary to find that point. Or do we ever really know?
You have to assume that every attacker already has some information
about you or your password. Probably he knows that you are using
repetition patterns in all or many of your passwords, which makes
attacking it much easier.
Think of your adversary standing behind you while you type in your
password. He doesn't see what password you're typing, but he certainly
hears the repetition patterns. If you're using SSH challenge-response
authentication, then he might even sniff the traffic to find that out,
because it reveals the pauses between key-presses.
Regards,
Ertugrul Söylemez.
--=20
Security is the one concept, which makes things in your life stay as
they are. Otto is a man, who is afraid of changes in his life; so
naturally he does not employ security.
On Sat, 28 Jul 2007 02:01:26 +0200, Ertugrul Soeylemez
>You have to assume that every attacker already has some information
>about you or your password. Probably he knows that you are using
>repetition patterns in all or many of your passwords, which makes
>attacking it much easier.
Quality of user passwords allows bad things. For example, one (quite
typical) online site had average password entropy (strength) less than
15 bits. So, If users can and use that kind of lousy passwords,
attacker has good chances for brute-forcing files without needing much
of that extra information.
http://groups.google.com/group/sci.crypt/msg/cfacf77ca70fd95 b?&hl=en
36ec2f330ba175cdc1aacbdcb812036c
83240670a27ad2bdc2c5a1b36222d3941aaf4bca
a2da3cafba3cd23391ad90511b7c7b73fa219492
64799812b5ee98a4cc1c6484bf8f849e3fee9aa6553393b9d7873b7f8cac 9b825aca648a365aaa5e7037f903d708e19df2198dfa82b2933b14ac7aa7 072101eb
On Sat, 28 Jul 2007 16:22:44 +0300, rgesw wrote:
> On Sat, 28 Jul 2007 02:01:26 +0200, Ertugrul Soeylemez
>
>
>>You have to assume that every attacker already has some information
>>about you or your password. Probably he knows that you are using
>>repetition patterns in all or many of your passwords, which makes
>>attacking it much easier.
>
> Quality of user passwords allows bad things. For example, one (quite
> typical) online site had average password entropy (strength) less than
> 15 bits. So, If users can and use that kind of lousy passwords,
> attacker has good chances for brute-forcing files without needing much
> of that extra information.
>
> http://groups.google.com/group/sci.crypt/msg/cfacf77ca70fd95 b?&hl=en
>
> 36ec2f330ba175cdc1aacbdcb812036c
> 83240670a27ad2bdc2c5a1b36222d3941aaf4bca
> a2da3cafba3cd23391ad90511b7c7b73fa219492
> 64799812b5ee98a4cc1c6484bf8f849e3fee9aa6553393b9d7873b7f8cac 9b825aca648a365aaa5e7037f903d708e19df2198dfa82b2933b14ac7aa7 072101eb
This "quality" is an elusive goal. I used the same password for two
email accts, one came back "weak". the other "strong" lol
--
"You can't trust code that you did not totally create yourself"
Ken Thompson "Reflections on Trusting Trust"
http://www.acm.org/classics/sep95/
On Sat, 28 Jul 2007 02:01:26 +0200, Ertugrul Soeylemez wrote:
> Ari
>
>>> > Would you consider either of these serious passwords?
>>> >
>>> > 6:Q?-jiF6:Q?-jiF
>>> > 6:Q?-jiFFij-?Q:6
>>>
>>> Not really. Probably they are impractical to break for a random
>>> attacker, but it's still safer to use a completely random string
>>> without repetition. Then it also doesn't have to be so long.
>>
>> I suppose this is the crux of my argument. On the order of
>> practicality, it is best to have the shortest possible password
>> (easiest to remember). You will need to have several (all eggs in one
>> basket = no good). so the shorter the better.
>>
>> Unless the examples above, again rearranged so to be easily remembered
>> are, or combined into 32 character passwords...
>>
>> Where is the point of best safety? One must assume a powerful
>> adversary to find that point. Or do we ever really know?
>
> You have to assume that every attacker already has some information
> about you or your password. Probably he knows that you are using
> repetition patterns in all or many of your passwords, which makes
> attacking it much easier.
>
> Think of your adversary standing behind you while you type in your
> password. He doesn't see what password you're typing, but he certainly
> hears the repetition patterns. If you're using SSH challenge-response
> authentication, then he might even sniff the traffic to find that out,
> because it reveals the pauses between key-presses.
>
> Regards,
> Ertugrul Söylemez.
That's a good lesson, Er, thanks.
--
"You can't trust code that you did not totally create yourself"
Ken Thompson "Reflections on Trusting Trust"
http://www.acm.org/classics/sep95/