is it secure?

[Pasquale Frega]

i think yes:

variable _leng 8;
variable _char_set {Mm4oIRPkUSyB3ajX7JQfvW0hdstZz1EilDH96xYOg5qp2bAuewnCcGTKrVFNL8};
variable _password;

for {set _count 1} {$_count <= $_leng} {incr _count} {
set _random_set {};

# Generate random set

set _index 0;
while {$_index < [string length $_char_set]} {
set _random_index [expr {int(rand() * [string length $_char_set])}];
if {[string first [string index $_char_set $_random_index] $_random_set] == -1} {
set _random_set $_random_set[string index $_char_set $_random_index];
incr _index;
}
}

# Append a char to the password from random set

set _password $_password[string index $_random_set [expr {int(rand() * [string length $_random_set])}]];
}

puts $_password;

[Peter Lewerin]

I'd say it's fairly secure (at least I hope so, because it's very similar to what I use, approximated below).

package require math

proc passwd {} {
set chars 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
set length [string length $chars]
for {set i 0} {$i < 8} {incr i} {
append password [string index $chars [::math::random $length]]
}
return $password
}

[Pasquale Frega]

On Sun, 10 Apr 2016 10:17:31 +0200
Pasquale Frega <pask...@tiscali.it> wrote:

now is better:

set _char_set $_random_set;
}

puts $_password;

[Rich]

Pasquale Frega <pask...@tiscali.it> wrote:
> i think yes:

Depends upon who you are securing against.

> set _random_index [expr {int(rand() * [string length $_char_set])}];

^^^^^^
This is not secure:--------------/

Note the documentation of rand() from the mathfunc manual page:

The generator algorithm is a simple linear congruential generator
that is not cryptographically secure. Each result from rand
completely determines all future results from subsequent calls to
rand, so rand should not be used to generate a sequence of secrets,
such as one-time passwords.

So, if you are securing against your flatmate randomly guessing your
password by typing stuff in - then it is probably ok.

But if you are attempting to secure against a knowledgable adversary,
no, it is not at all secure.

[Pasquale Frega]

On Sun, 10 Apr 2016 17:04:14 -0000 (UTC)
Rich <ri...@example.invalid> wrote:

> Pasquale Frega <pask...@tiscali.it> wrote:
> > i think yes:
>
> Depends upon who you are securing against.
>
> > set _random_index [expr {int(rand() * [string length $_char_set])}];
> ^^^^^^
> This is not secure:--------------/
>
> Note the documentation of rand() from the mathfunc manual page:
>
> The generator algorithm is a simple linear congruential generator
> that is not cryptographically secure. Each result from rand
> completely determines all future results from subsequent calls to
> rand, so rand should not be used to generate a sequence of secrets,
> such as one-time passwords.
>

so every approach with rand is not secure... i think,
with tcl as well as with the others.

There is no way to make a secure password if not by yourself.

[Rich]

Pasquale Frega <pask...@tiscali.it> wrote:
> i think yes:

If you are using Linux, there is a secure way to generate a random
password:

#!/usr/bin/tclsh

proc generate_password {password_length} {
set fd [open /dev/urandom {RDONLY BINARY}]
fconfigure $fd -buffersize 10 ;# don't waste random bytes
set password ""
while {[string length $password] < $password_length} {
binary scan [read $fd 1] cu value
# skip byte values that are not printable ASCII
if {$value < 33 || 126 < $value} {
continue
}
append password [format %c $value]
}
close $fd
return $password
}

puts [generate_password 16]
puts [generate_password 32]
puts [generate_password 64]

Output from a test run:

=Srm3.:bVVFGjz(r
4gNa8ODXDtt"JEfTh#%iI'j-*_LsV$?H
/0'BMufg=zJr9M4~[gD(T^1SA<8MV/8R#KL.,~DxDO+p#U)kA5a0QF$!r;>3OA%,

And from a second test run:

NDf(!_,D-606`*q%
Eb1w=yy6Y$BBel)f[Dr>6a"5#qjjr'X?
&Nog^!bP:8}d3^nVs*ioIA4{b|Pu+^p@vsn0ZB0HMp+v%%I9y^C|VO95Q)>M@p1P

The above are significanly more secure than deriving a password from
the built in rand() function.

Note, the proc only outputs printable 7-bit ASCII characters.

[Brad Lanam]

On Sunday, April 10, 2016 at 1:18:27 AM UTC-7, Pasquale Frega wrote:
> variable _char_set {Mm4oIRPkUSyB3ajX7JQfvW0hdstZz1EilDH96xYOg5qp2bAuewnCcGTKrVFNL8};

Randomizing the character set you choose from will not make it any
more or less secure, nor more random. This just obfuscates your code
for no good reason.

Making your password longer than eight characters will help more than
anything. A format such as:
abcdef12-abcdef12
Where the separator character is also chosen randomly would be much better.

And then you will be back to the problem Rich states. If someone *really*
wants to get in, they will.

[Rich]

For Tcl, using the output of rand() for cryptographically secure
randomness is not at all secure.

Again, however, it also depends upon your use. For generating a
password that another user of your computer might try to randomly guess
by typing, it would thwart that attack.

For generating a password to protect your startups grand idea from
Chinese spys and thiefs, no, it is not secure against that at all.

> There is no way to make a secure password if not by yourself.

There are plenty of ways, but they all begin with use of a
cryptographically secure random number generator, and proper seeding of
that random number generator.

[Rich]

Brad Lanam <brad....@gmail.com> wrote:
> On Sunday, April 10, 2016 at 1:18:27 AM UTC-7, Pasquale Frega wrote:
> > variable _char_set {Mm4oIRPkUSyB3ajX7JQfvW0hdstZz1EilDH96xYOg5qp2bAuewnCcGTKrVFNL8};

> Randomizing the character set you choose from will not make it any
> more or less secure, nor more random. This just obfuscates your code
> for no good reason.

Also true. The random element should be applied to the choice of which
character to choose, not in the ordering of the input set.

> Making your password longer than eight characters will help more than
> anything.

Also true. The character set above is is numerals, uppercase English
and lowercase English letters. For a total of 62 characters. An eight
character password chosen from a set of 62 characters has a total of
62^8 possible combinations, or 218,340,105,584,896 total combinations.
This is secure against human brute force attack using a keyboard, but
not against automated computer brute force.

> A format such as:
> abcdef12-abcdef12
> Where the separator character is also chosen randomly would be much
> better.

Yep, in almost all instances the easy way to make a password more
secure is simply to lengthen the password.

> And then you will be back to the problem Rich states. If someone
> *really* wants to get in, they will.

Yep. The reason why I started with "it depends upon who you are
defending against". There's a huge difference between protecting
against another random user of your computer with no knowledge of
breaking passwords vs. defending against the NSA or GHCQ should they
decide you are interesting enough to target.

[Pasquale Frega]

Thanks, i already know this.

[Rich]

The implementation of math::random uses Tcl's rand() generator
internally:

proc ::math::random {args} {
set num [expr {rand()}]
^^^^^^
if { [llength $args] == 0 } {
return $num
} elseif { [llength $args] == 1 } {
return [expr {int($num * [lindex $args 0])}]
} elseif { [llength $args] == 2 } {
foreach {lower upper} $args break
set range [expr {$upper - $lower}]
return [expr {int($num * $range) + $lower}]
} else {
set fn [lindex [info level 0] 0]
error "wrong # args: should be \"$fn ?value1? ?value2?\""
}
}

So it has all of the same 'randomness' issues described in the mathfunc
page re. the rand() function.

[David Zolli - Kroc]

Le lundi 11 avril 2016 00:47:40 UTC+2, Rich a écrit :

> So it has all of the same 'randomness' issues described in the mathfunc
> page re. the rand() function.

This can be a little bit improved by adding current time in the random process:

expr {rand()*[clock microsecond]}

[Pasquale Frega]

About this?

variable _char_set {1234567890qwertyuioplkjhgfdsazxcvbnmQWERTYUIOPLKJHGFDSAZXCVBNM};
variable _password {};

expr {srand([clock microseconds] - [file atime /])};
for {set _len 1} {$_len <= 8} {incr _len} {
set _password $_password[string index $_char_set [expr {int(rand() * [string length $_char_set])}]];
}

puts $_password;

[Rich]

Using a different seed to a poor quality random number generator
creates -- a poor quality set of random numbers. Any algorithm that
uses the default rand() will have the same non-randomness issues as set
out in the mathfunc man page.

Again, whether this is 'secure' depends upon your threat model. If you
are using it to prevent humans typing on keyboards from guessing your
passwords, then it is ok. Plus if you are using it to pick separate
independent passwords, one each per service you use that needs a
password, then this is much better than the typical use of the
identical password everywhere that is so prevalent.

You also provide yourself some minimal protection against a service
having their password hash database captured and decrypted, because by
avoiding the common "word123$" pattern, you make all of the
Jack-the-Ripper attacks more difficult because none of the input word
or pattern files will compute this password. That leaves only a brute
force attack for those guys. Which at only 8 characters long, is also
feasable for them to perform.

But if you are protecting corporate secrets from chinese spys, no, this
is not secure.

[Brad Lanam]

On Monday, April 11, 2016 at 3:07:50 AM UTC-7, Rich wrote:

It is hard to pick a good seed -- poor quality seeds can often be
replicated (so many people use [clock seconds]).

See: http://perldoc.perl.org/5.14.0/functions/srand.html

I'm using this:

expr {srand([clock seconds] ^ [clock microseconds] ^ [pid])}

but it's just for random numbers, not passwords. And as you can see
from the document, may not be that great.

Seeding the random number from a checksum of some /dev/random
output would probably work well.

[Rich]

Brad Lanam <brad....@gmail.com> wrote:
> On Monday, April 11, 2016 at 3:07:50 AM UTC-7, Rich wrote:
> > Pasquale Frega <pasquae...@tiscali.it> wrote:
> > > On Sun, 10 Apr 2016 18:53:52 -0000 (UTC)
> > > Rich <rich @ example.invalid> wrote:
> >
> > > > There are plenty of ways, but they all begin with use of a
> > > > cryptographically secure random number generator, and proper
> > > > seeding of that random number generator.
> >
> > > About this?
> >
> > > variable _char_set {1234567890qwertyuioplkjhgfdsazxcvbnmQWERTYUIOPLKJHGFDSAZXCVBNM};
> > > variable _password {};
> >
> > > expr {srand([clock microseconds] - [file atime /])};
> > > for {set _len 1} {$_len <= 8} {incr _len} {
> > > set _password $_password[string index $_char_set [expr {int(rand() * [string length $_char_set])}]];
> > > }
> >
> > > puts $_password;
> >
> > Using a different seed to a poor quality random number generator
> > creates -- a poor quality set of random numbers. Any algorithm that
> > uses the default rand() will have the same non-randomness issues as set
> > out in the mathfunc man page.

> It is hard to pick a good seed -- poor quality seeds can often be
> replicated (so many people use [clock seconds]).

One of the hardest things to do in CS. And cryptographically secure
random number generation depends upon picking a good seed.

> See: http://perldoc.perl.org/5.14.0/functions/srand.html

> I'm using this:

> expr {srand([clock seconds] ^ [clock microseconds] ^ [pid])}

> but it's just for random numbers, not passwords. And as you can see
> from the document, may not be that great.

A cryptographer would likely say it is not great at all, for
cryptographic use. For other random number uses (games, etc.) it is
perfectly fine.

> Seeding the random number from a checksum of some /dev/random
> output would probably work well.

If you have /dev/random, then you should also have /dev/urandom, and if
so, for secure needs, one is better off just using the output from
/dev/urandom directly rather than trying to jump through other hoops.

[David Zolli - Kroc]

Le lundi 11 avril 2016 23:35:55 UTC+2, Rich a écrit :
> If you have /dev/random, then you should also have /dev/urandom, and if
> so, for secure needs, one is better off just using the output from
> /dev/urandom directly rather than trying to jump through other hoops.

As I have no idea about the difference between /dev/random and /dev/urandom and only basic knowledges about cryptography, I asked Google and got this very interesting page:

http://www.2uo.de/myths-about-urandom/

[Emmanuel Frecon]

Maybe is this better for generating random numbers? http://wiki.tcl.tk/13121

[M. Strobel]

I would like to add this to the discussion.

I am more concerned by the problem you have to write down your truly/untruly
random and completely meaningless (no semantics) passwords > 12 characters
on paper or store it in the system.

Your house is not secure. On your system you need to password-protect it.

:-) /Str.

[Pasquale Frega]

Whats about this?

paskali@zemir:~$ tclsh
% variable _seed [pid];
% proc password {} {
global _seed;
variable _password {};
variable _set {shW4UMe832TpaSylIdfzxbrNki9A7Q5PmZ0XDuYVg1KEGwLcJtjRCF6OqovBHn};

incr _seed [lindex [time {
for {set _index 1} {$_index <= 8} {incr _index} {
set _password $_password[string index $_set [expr {int(rand() * [string length $_set])}]];
}
}] 0];

return $_password;
}
% password
GwfeVGcB
% password
p6MzQ6eo
% password
rEupYb0c
% password
1Dltmnoj
% password
hmbHLjod
% password
DX6xTPCr
% password
nfpDiOzV
% password
WXuW9JMy
%

[Pasquale Frega]

Pardon, i forget srand:

paskali@zemir:~$ tclsh
% variable _seed [pid];
% proc password {} {
global _seed;
variable _password {};
variable _set {shW4UMe832TpaSylIdfzxbrNki9A7Q5PmZ0XDuYVg1KEGwLcJtjRCF6OqovBHn};

incr _seed [lindex [time {

expr {srand($_seed)};

for {set _index 1} {$_index <= 8} {incr _index} {
set _password $_password[string index $_set [expr {int(rand() * [string length $_set])}]];
}
}] 0];

return $_password;
}
% password

H3BfTRdh
% password
gbJFk0AX
% password
FjWNzJvp
% password
tLrRjoMA
% password
nSYbw2u4
% password
4qixAx9n
% password
k8ekuYuf
% password
FMdHBvQI
% password
mmKrhnIT
%

[Brad Lanam]

On Wednesday, April 13, 2016 at 1:09:47 AM UTC-7, M. Strobel wrote:
> I would like to add this to the discussion.
>
> I am more concerned by the problem you have to write down your truly/untruly
> random and completely meaningless (no semantics) passwords > 12 characters
> on paper or store it in the system.
>
> Your house is not secure. On your system you need to password-protect it.
>
> :-) /Str.

And this is the classic xkcd comic that goes along with this:

https://xkcd.com/936/

[Peter Lewerin]

Systems that we make passwords for typically reject "non-strong" passwords, accepting only character-salad passwords that are so hard to remember that we need to store them somehow. Myself, I use that simple algorithm I posted above, hide the password list and change my passwords often. I can't really say how secure my data are, but that's also because I don't know how secure my browser really is, or how hard the systems are to hack. Sometimes one has to settle for good enough.

[Rich]

Pasquale Frega <pasqual...@tiscali.it> wrote:
> On Wed, 13 Apr 2016 16:13:38 +0200
> Pasquale Frega <pasqual...@tiscali.it> wrote:

> > On Sun, 10 Apr 2016 18:53:52 -0000 (UTC)
> > Rich <ri...@example.invalid> wrote:
> >
> > >
> > > There are plenty of ways, but they all begin with use of a
> > > cryptographically secure random number generator, and proper seeding of
> > > that random number generator.
> > >
> >
> > Whats about this?
> >
> > paskali@zemir:~$ tclsh
> > % variable _seed [pid];

From an "is is secure?" standpoint - no, nothing you can do will make
Tcl's rand() generator "secure" (in a general sense).

Is it good enough to generate better randomized passwords than you
would do yourself, manually: yes. Humans are very bad at 'randomly'
generating anything. Is it secure against a knowledgeable attacker:
no.

Again, you need to define your threat model (something you've avoided
now across multiple posts) in order to make any call as to "secure".
There is an extreme gap between "secure against my nine year old little
brother" and "secure against NSA spying". So far, you've failed, even
after having been prodded several times, to provide any definition of
whom you are trying to secure against. Without that definition, the
only answer that is safe when it comes to using Tcl's default rand()
generator is: no - not secure.

Note, the hard part about generating secure random numbers is picking a
seed value. The seed itself needs to be *randomly* generated. There's
a huge catch-22 there unless you've got some form of radioactive decay
(or other) physical random number generator available.

Also using [pid] as a seed is not secure. Nor is using the output from
[clock] secure. *Any* deterministic input as a seed makes the
resulting pseudo-random number generator insecure. There have been
numerous breaks throughout history of different cryptosystems where the
break was because a non-random seed was chosen for a high quality
cryptographic random number generator.

[Rich]

Peter Lewerin <plew...@gmail.com> wrote:

> Systems that we make passwords for typically reject "non-strong"
> passwords, accepting only character-salad passwords that are so hard
> to remember that we need to store them somehow. Myself, I use that
> simple algorithm I posted above, hide the password list and change my
> passwords often.

I use Password Gorilla (https://github.com/zdia/gorilla/wiki) for the
storage and use part of that equation myself.

In this case, for the purpose of:
1) using a different, unique, password for each site
2) avoiding Jack-The-Ripper patterns like Pa$$word843
3) avoiding the fact that humans are *very* bad at randomly
generating anything without assistance from tools (dice, etc.)

Then the simple algorithm is fine, and your passwords will likely
survive even having a password database dump (provided the server side
isn't storing them in plaintext) attacked by password crackers.

> I can't really say how secure my data are, but that's also because I
> don't know how secure my browser really is, or how hard the systems
> are to hack. Sometimes one has to settle for good enough.

In this case, there's soo much low-hanging fruit out there (the people
using passwords like Summer44! and thinking they are safe) that you
likely have nothing at all to worry about, even with the insure aspects
of rand()'s algorithm taken into account.

For a loose real-world analogy, your generated passwords are like car
door locks. They don't _really_ prevent anyone from breaking in, but
they increase the trouble just enough that most thieves will simply
continue looking for the unlocked car to rifle through instead.

[Pasquale Frega]

Where are rand and srand?

paskali@zemir:~$ tclsh
% variable _index [pid];
% proc password {} {
global _index;
variable _set {shW4UMe832TpaSylIdfzxbrNki9A7Q5PmZ0XDuYVg1KEGwLcJtjRCF6OqovBHn};
variable _password {};

for {set _len 1} {$_len <= 8} {incr _len} {

incr _index [lindex [time {
while {$_index >= [string length $_set]} {
incr _index -[string length $_set];
}
set _password $_password[string index $_set $_index];

}] 0];
}

return $_password;
}
% password

OWeZSqS6
% password
akMcML8j
% password
8fhEhE8j
% password
3zhEhKUc
% password
UyvIolBK
% password
rZyqS6ly
% password
q9ieJpOS
% password
6NNWGWtP
% password
TrUcMLT3
% password
RbbhEhJ5
% password
TrULULet
% password
ednznf4h
% password
EapFpC2O
%

[Rich]

Pasquale Frega <pasqual...@tiscali.it> wrote:
> On Sun, 10 Apr 2016 18:53:52 -0000 (UTC)
> Rich <ri...@example.invalid> wrote:

> >
> > There are plenty of ways, but they all begin with use of a
> > cryptographically secure random number generator, and proper
> > seeding of that random number generator.
> >

> Where are rand and srand?

In which case this is fully deterministic and not at all secure.

[Pasquale Frega]

On Thu, 14 Apr 2016 12:38:06 -0000 (UTC)

Rich <ri...@example.invalid> wrote:

> Pasquale Frega <pasqual...@tiscali.it> wrote:
> > On Sun, 10 Apr 2016 18:53:52 -0000 (UTC)
> > Rich <ri...@example.invalid> wrote:
>
> > >
> > > There are plenty of ways, but they all begin with use of a
> > > cryptographically secure random number generator, and proper
> > > seeding of that random number generator.
> > >
>
> > Where are rand and srand?
>
> In which case this is fully deterministic and not at all secure.
>

What do you determinate? And where? And when? My
processor speed? My RAM usage? My active process?...

[Rich]

Pasquale Frega <pasqual...@tiscali.it> wrote:
> On Thu, 14 Apr 2016 12:38:06 -0000 (UTC)
> Rich <ri...@example.invalid> wrote:

> > Pasquale Frega <pasqual...@tiscali.it> wrote:
> > > On Sun, 10 Apr 2016 18:53:52 -0000 (UTC)
> > > Rich <ri...@example.invalid> wrote:
> >
> > > > There are plenty of ways, but they all begin with use of a
> > > > cryptographically secure random number generator, and proper
> > > > seeding of that random number generator.
> >
> > > Where are rand and srand?
> >
> > In which case this is fully deterministic and not at all secure.

> What do you determinate? And where? And when? My
> processor speed? My RAM usage? My active process?...

The output from the generator is deterministic in that as soon as an
attacker has worked out the inputs that generated the first letter, it
is simply a matter of computing the remaining letters.

I am beginning to suspect that you are trolling. You've completely
failed to provide any statement of the threat model you are defending
against (despite being prodded to do so multiple times already).

And you continue to persist in creating additional code snippets
without paying any attention to what anyone is telling you, nor seeming
to learn from anything anyone is telling you. You are falling smack
into "Shiner's Law"
(https://www.schneier.com/blog/archives/2011/04/schneiers_law.html).

In which case, this will likely be the last communication you hear from
me. If others want to respond to you, fine.

[Pasquale Frega]

Sorry, but i am sure my alghoritm is secure. Simply i tell you is possible
to create (pseudo)random without rand and srand, so this make the
password (at least) a bit more secure.

Regards and sorry again

[Pasquale Frega]

My algorithm could be found here:

http://wiki.tcl.tk/43887

i am testing it yet, any suggestion of course is
welcomed.

[Brad Lanam]

Using the 'ent' program:

Peter's Algorithm:

Entropy = 5.953665 bits per byte.

Optimum compression would reduce the size
of this 80000 byte file by 25 percent.

Chi square distribution for 80000 samples is 250565.19, and randomly
would exceed this value 0.01 percent of the times.

Arithmetic mean value of data bytes is 86.8291 (127.5 = random).
Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).
Serial correlation coefficient is -0.003936 (totally uncorrelated = 0.0).

OP's algorithm:

Entropy = 4.787082 bits per byte.

Optimum compression would reduce the size
of this 80000 byte file by 40 percent.

Chi square distribution for 80000 samples is 841393.86, and randomly
would exceed this value 0.01 percent of the times.

Arithmetic mean value of data bytes is 93.7709 (127.5 = random).
Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).
Serial correlation coefficient is -0.204070 (totally uncorrelated = 0.0).

Note how much better the serial correlation coefficient is with the
pseudo random number generator.

Many of the other values are not so useful due to the limited data range
[0-9A-Za-z] of the data, but you can compare Peter's against the OP's.

Compare the compression percentages: Peter's: 25% OP's: 40%.
There's a lot more repetition in the OP's algorithm.

[Brad Lanam]

And just for fun:

80000 characters from /dev/urandom:

Entropy = 7.997841 bits per byte.

Optimum compression would reduce the size

of this 80000 byte file by 0 percent.

Chi square distribution for 80000 samples is 238.13, and randomly
would exceed this value 75.00 percent of the times.

Arithmetic mean value of data bytes is 127.2634 (127.5 = random).
Monte Carlo value for Pi is 3.159678992 (error 0.58 percent).
Serial correlation coefficient is 0.001883 (totally uncorrelated = 0.0).

Serial correlation coefficient is excellent (and you can see that ::math::random is quite decent).
Chi square is pretty good, not great.

Given these numbers, I would trust /dev/urandom to be quite random.

[Peter Lewerin]

My old (~25 years ago) password generation algorithm was that I owned a (facsimile edition of a) really rare book in Latin, and I used to take 4-5 words at a time from that and join them up for a password, noting the page number in a list. Of course, if anyone had guessed what book I was using it would have been quite transparent. I had to give that habit up when plain-text passwords went out of style. I don't even know how to start calculating the statistics for this one, but if anyone could, I'd be really interested.

[Christian Gollwitzer]

Am 15.04.16 um 22:44 schrieb Peter Lewerin:

It would be very similar to this algorithm https://xkcd.com/936/ and I
think it is sometimes called "passphrase" as opposed to "password". Only
because of ridiculous password policy, these secure passphrases are
rarely accepted in practice.

Christian

[Pasquale Frega]

Made a small update, now i think is better.

[Pasquale Frega]

Update, now the previous test should be something like this:

Entropy = 5.953689 bits per byte.

Optimum compression would reduce the size
of this 80000 byte file by 25 percent.

Chi square distribution for 80000 samples is 250555.01, and randomly
would exceed this value less than 0.01 percent of the times.

Arithmetic mean value of data bytes is 86.9527 (127.5 = random).

Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).

Serial correlation coefficient is 0.000435 (totally uncorrelated = 0.0).

[Brad Lanam]

On Saturday, April 16, 2016 at 6:39:56 AM UTC-7, Pasquale Frega wrote:
> Update, now the previous test should be something like this:
>
> Entropy = 5.953689 bits per byte.
>
> Optimum compression would reduce the size
> of this 80000 byte file by 25 percent.
>
> Chi square distribution for 80000 samples is 250555.01, and randomly
> would exceed this value less than 0.01 percent of the times.
>
> Arithmetic mean value of data bytes is 86.9527 (127.5 = random).
> Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).
> Serial correlation coefficient is 0.000435 (totally uncorrelated = 0.0).

Why did you copy the /dev/urandom output and imply that your program
would match it?

The latest numbers (This is a horrible password generator):
Using that character occurence table, it would be really easy to brute
force the passwords created by this algorithm.

Entropy = 3.753542 bits per byte.

Optimum compression would reduce the size

of this 80000 byte file by 53 percent.

Chi square distribution for 80000 samples is 1668541.12, and randomly

would exceed this value 0.01 percent of the times.

Arithmetic mean value of data bytes is 101.3792 (127.5 = random).

Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).

Serial correlation coefficient is -0.048597 (totally uncorrelated = 0.0).

The character occurrence table:

Value Char Occurrences Fraction
48 0 64 0.000800
49 1 31 0.000387
50 2 12 0.000150
51 3 17 0.000212
52 4 11 0.000138
53 5 122 0.001525
54 6 11 0.000138
55 7 183 0.002288
56 8 18 0.000225
57 9 1063 0.013288
65 A 277 0.003462
66 B 12 0.000150
67 C 17 0.000212
68 D 64 0.000800
69 E 25 0.000313
70 F 17 0.000212
71 G 15 0.000188
72 H 10 0.000125
73 I 6791 0.084888
74 J 13 0.000162
75 K 24 0.000300
76 L 17 0.000212
77 M 11 0.000138
78 N 7556 0.094450
79 O 14 0.000175
80 P 111 0.001388
81 Q 152 0.001900
82 R 7 0.000087
83 S 309 0.003863
84 T 17 0.000212
85 U 10 0.000125
86 V 41 0.000513
87 W 12 0.000150
88 X 62 0.000775
89 Y 52 0.000650
90 Z 98 0.001225
97 a 120 0.001500
98 b 7842 0.098025
99 c 13 0.000162
100 d 7534 0.094175
101 e 15 0.000188
102 f 7720 0.096500
103 g 21 0.000262
104 h 15 0.000188
105 i 3328 0.041600
106 j 21 0.000262
107 k 7020 0.087750
108 l 4747 0.059338
109 m 102 0.001275
110 n 8 0.000100
111 o 13 0.000162
112 p 15 0.000188
113 q 11 0.000138
114 r 7738 0.096725
115 s 15 0.000188
116 t 20 0.000250
117 u 46 0.000575
118 v 12 0.000150
119 w 19 0.000237
120 x 7718 0.096475
121 y 817 0.010212
122 z 7804 0.097550

Total: 80000 1.000000

[Rich]

Brad Lanam <brad....@gmail.com> wrote:
> On Saturday, April 16, 2016 at 6:39:56 AM UTC-7, Pasquale Frega wrote:
> > Update, now the previous test should be something like this:
> >
> > Entropy = 5.953689 bits per byte.
> >
> > Optimum compression would reduce the size
> > of this 80000 byte file by 25 percent.
> >
> > Chi square distribution for 80000 samples is 250555.01, and randomly
> > would exceed this value less than 0.01 percent of the times.
> >
> > Arithmetic mean value of data bytes is 86.9527 (127.5 = random).
> > Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).
> > Serial correlation coefficient is 0.000435 (totally uncorrelated = 0.0).

> Why did you copy the /dev/urandom output and imply that your program
> would match it?

Likely because he has zero background in cryptography or random number
generation, yet he thinks he knows better than those who do. He's
falling into the

And he is trying to make an otherwise horrible system appear to be
good.

> The latest numbers (This is a horrible password generator):

Agreed.

He's falling smack into the "Schiner's Law" trap
(https://www.schneier.com/blog/archives/2011/04/schneiers_law.html) yet
his Dunning-Kruger effect
(https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect) factor is
so high he has no idea that he is anywhere near the "Schiner's Law"
trap.

[Pasquale Frega]

PII 366 Mhz

Value Char Occurrences Fraction
48 0 1346 0.016825
49 1 1254 0.015675
50 2 1289 0.016112
51 3 1279 0.015988
52 4 1280 0.016000
53 5 1298 0.016225
54 6 1184 0.014800
55 7 1333 0.016663
56 8 1332 0.016650
57 9 1241 0.015513
65 A 1262 0.015775
66 B 1322 0.016525
67 C 1259 0.015738
68 D 1318 0.016475
69 E 1224 0.015300
70 F 1268 0.015850
71 G 1335 0.016688
72 H 1249 0.015612
73 I 1294 0.016175
74 J 1285 0.016063
75 K 1323 0.016538
76 L 1296 0.016200
77 M 1292 0.016150
78 N 1261 0.015762
79 O 1223 0.015288
80 P 1310 0.016375
81 Q 1289 0.016112
82 R 1300 0.016250
83 S 1252 0.015650
84 T 1337 0.016713
85 U 1320 0.016500
86 V 1293 0.016162
87 W 1303 0.016287
88 X 1312 0.016400
89 Y 1310 0.016375
90 Z 1290 0.016125
97 a 1360 0.017000
98 b 1326 0.016575
99 c 1253 0.015662
100 d 1302 0.016275
101 e 1244 0.015550
102 f 1307 0.016338
103 g 1330 0.016625
104 h 1267 0.015838
105 i 1349 0.016862
106 j 1290 0.016125
107 k 1290 0.016125
108 l 1215 0.015187
109 m 1288 0.016100
110 n 1273 0.015912
111 o 1272 0.015900
112 p 1308 0.016350
113 q 1363 0.017038
114 r 1269 0.015863
115 s 1281 0.016012
116 t 1339 0.016737
117 u 1281 0.016012
118 v 1257 0.015713
119 w 1276 0.015950
120 x 1295 0.016188
121 y 1280 0.016000
122 z 1322 0.016525

Total: 80000 1.000000

Entropy = 5.953637 bits per byte.

Optimum compression would reduce the size
of this 80000 byte file by 25 percent.

Chi square distribution for 80000 samples is 250577.73, and randomly

would exceed this value less than 0.01 percent of the times.

Arithmetic mean value of data bytes is 86.9505 (127.5 = random).

Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).

Serial correlation coefficient is 0.000214 (totally uncorrelated = 0.0).

[Pasquale Frega]

AMD E-450 1650Mhz

48 0 1344 0.016800
49 1 1192 0.014900
50 2 1318 0.016475
51 3 1414 0.017675
52 4 1251 0.015637
53 5 1213 0.015163
54 6 1324 0.016550
55 7 1406 0.017575
56 8 1354 0.016925
57 9 1432 0.017900
65 A 1455 0.018187
66 B 1222 0.015275
67 C 1225 0.015313
68 D 1454 0.018175
69 E 1289 0.016112
70 F 1261 0.015762
71 G 1299 0.016237
72 H 1347 0.016837
73 I 1300 0.016250
74 J 1241 0.015513
75 K 1218 0.015225
76 L 1310 0.016375
77 M 1223 0.015288
78 N 1250 0.015625
79 O 1324 0.016550
80 P 1214 0.015175
81 Q 1284 0.016050
82 R 1144 0.014300
83 S 1132 0.014150
84 T 1333 0.016663
85 U 1211 0.015138
86 V 1226 0.015325
87 W 1399 0.017488
88 X 1396 0.017450
89 Y 1291 0.016137
90 Z 1205 0.015063
97 a 1287 0.016088
98 b 1252 0.015650
99 c 1312 0.016400
100 d 1367 0.017087
101 e 1244 0.015550
102 f 1508 0.018850
103 g 1149 0.014363
104 h 1345 0.016813
105 i 1344 0.016800
106 j 1250 0.015625
107 k 1206 0.015075
108 l 1270 0.015875
109 m 1211 0.015138
110 n 1306 0.016325
111 o 1241 0.015513
112 p 1279 0.015988
113 q 1309 0.016362
114 r 1200 0.015000
115 s 1361 0.017013
116 t 1194 0.014925
117 u 1410 0.017625
118 v 1166 0.014575
119 w 1385 0.017313
120 x 1321 0.016512
121 y 1176 0.014700
122 z 1406 0.017575

Total: 80000 1.000000

Entropy = 5.951122 bits per byte.

Optimum compression would reduce the size
of this 80000 byte file by 25 percent.

Chi square distribution for 80000 samples is 251738.34, and randomly

would exceed this value less than 0.01 percent of the times.

Arithmetic mean value of data bytes is 86.7243 (127.5 = random).

Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).

Serial correlation coefficient is -0.001069 (totally uncorrelated = 0.0).

[Pasquale Frega]

>
> Likely because he has zero background in cryptography
>

you are 100

[Pasquale Frega]

Which processor do you have?

[Pasquale Frega]

On WM8880 dual core cortex A9
(someting like an ARM, at least i think)

Value Char Occurrences Fraction
48 0 1298 0.016225
49 1 1326 0.016575
50 2 1338 0.016725
51 3 1311 0.016387
52 4 1278 0.015975
53 5 1231 0.015388
54 6 1307 0.016338
55 7 1271 0.015887
56 8 1274 0.015925
57 9 1343 0.016788
65 A 1293 0.016162
66 B 1298 0.016225
67 C 1311 0.016387
68 D 1260 0.015750
69 E 1258 0.015725
70 F 1294 0.016175
71 G 1296 0.016200
72 H 1292 0.016150
73 I 1288 0.016100
74 J 1360 0.017000
75 K 1289 0.016112
76 L 1293 0.016162
77 M 1307 0.016338
78 N 1312 0.016400
79 O 1346 0.016825
80 P 1280 0.016000
81 Q 1314 0.016425
82 R 1352 0.016900
83 S 1324 0.016550
84 T 1338 0.016725
85 U 1284 0.016050
86 V 1341 0.016762
87 W 1247 0.015588
88 X 1368 0.017100
89 Y 1342 0.016775
90 Z 1324 0.016550
97 a 1297 0.016213
98 b 1234 0.015425
99 c 1284 0.016050
100 d 1245 0.015562
101 e 1298 0.016225
102 f 1281 0.016012
103 g 1302 0.016275
104 h 1241 0.015513
105 i 1222 0.015275
106 j 1241 0.015513
107 k 1309 0.016362
108 l 1285 0.016063
109 m 1270 0.015875
110 n 1333 0.016663
111 o 1248 0.015600
112 p 1287 0.016088
113 q 1228 0.015350
114 r 1295 0.016188
115 s 1223 0.015288
116 t 1285 0.016063
117 u 1310 0.016375
118 v 1296 0.016200
119 w 1252 0.015650
120 x 1227 0.015338
121 y 1240 0.015500
122 z 1279 0.015988

Total: 80000 1.000000

Entropy = 5.953627 bits per byte.

Optimum compression would reduce the size
of this 80000 byte file by 25 percent.

Chi square distribution for 80000 samples is 250583.02, and randomly

would exceed this value less than 0.01 percent of the times.

Arithmetic mean value of data bytes is 86.6740 (127.5 = random).

Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).

Serial correlation coefficient is 0.003713 (totally uncorrelated = 0.0).

[Brad Lanam]

On Saturday, April 16, 2016 at 10:12:43 AM UTC-7, Pasquale Frega wrote:
> Which processor do you have?

What does it matter?
You appear to have created something that works on particular machines/
operating systems combinations (low-end processors).
Of what use is that?

Guess what happens when someone using your generator upgrades to a different computer/notebook/phone?

Linux Mint 17.3, Linux 3.19.0-32, i3-3110M 2.4Ghz x 4

And you have not thought about "M. Strobel"'s (et.al.) comment.
Of what use is a password that you have to write down?

[Pasquale Frega]

I think and i hope to have created something usefull to
anyone understand it, this is important for me.

The rest is irrelevant.

[M. Strobel]

On 16.04.2016 19:38, Pasquale Frega wrote:
> On WM8880 dual core cortex A9
> (someting like an ARM, at least i think)

So this is a random processor program? That runs on random processors
producing identical output?

Sorry, I could not resist. Your posts do not sound very reasonable.

Anyway, have fun with your procedure and Tcl.

/Str.

[Pasquale Frega]

On Mon, 18 Apr 2016 19:16:03 +0200
"M. Strobel" <str...@example.com> wrote:

>
> Anyway, have fun with your procedure and Tcl.
>
> /Str.

Thanks!