twitter: comp.lang.python - 25 new messages in 10 topics

comp.lang.python
http://groups.google.com/group/comp.lang.python?hl=en

comp.lang.python@googlegroups.com

Today's topics:

==============================================================================
TOPIC: What's Going on between Python and win7?
http://groups.google.com/group/comp.lang.python/t/ff028548e8841d37?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 23 2010 5:31 pm
From: Steven D'Aprano

On Tue, 23 Feb 2010 09:34:00 -0500, Jerry Hill wrote:

> On Mon, Feb 22, 2010 at 8:25 PM, W. eWatson <wolftracks@invalid.com>
> wrote:
>> So what's the bottom line? This link notion is completely at odds with
>> XP, and produces what I would call something of a mess to the unwary
>> Python/W7 user. Is there a simple solution?
>
> I know people went off on a tangent talking about symbolic links and
> hard links, but it is extremely unlikely that you created something like
> that by accident. Windows just doesn't create those without you doing
> quite a bit of extra work. It certainly doesn't create them when you
> drag & drop files around through the normal interface.

I find it far more likely that Windows 7 makes it easy for the user to
accidentally produce links rather than copies, rather than that Python
suddenly has developed a bug where it opens a completely different file
to the one you ask for.

But more likely still is some confusion regarding paths.

--
Steven

==============================================================================
TOPIC: When will Java go mainstream like Python?
http://groups.google.com/group/comp.lang.python/t/1675ca5386896fa5?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 23 2010 5:30 pm
From: Lie Ryan

On 02/24/10 12:08, Nobody wrote:
> On Wed, 24 Feb 2010 12:22:05 +1300, Lawrence D'Oliveiro wrote:
>
>>> Java - The JVM code been hacked to death by Sun engineers (optimised)
>>> Python - The PVM code has seen speed-ups in Unladen or via Pyrex..
>>> ad-infinitum but nowhere as near to JVM
>>
>> Python is still faster, though. I think a key reason is that its VM supports
>> reference-counting, which the Java folks never quite got the grasp of.
>
> So how does Python handle circular references?

There is an optional garbage collector built into the interpreter. Look
at here on how it works: http://python.ca/nas/python/gc/

== 2 of 2 ==
Date: Tues, Feb 23 2010 6:26 pm
From: George Sakkis

On Feb 23, 3:49 pm, mk <mrk...@gmail.com> wrote:

> Well I for one wouldn't want Python to go exactly Java way, see this:
>
> http://www.itjobswatch.co.uk/charts/permanent-demand-trend.aspx?s=jav...
>
> This is the percentage of job offers in UK where the keyword "Java" appears.
>
> Same for C#, it looks like C# is eating Java's lunch now:
>
> http://www.itjobswatch.co.uk/charts/permanent-demand-trend.aspx?s=csh...

This seems to be a UK-specific trend; in the US (and most other
countries I know of) Java is still going strong, e.g.
http://www.indeed.com/jobtrends?q=java%2C+c%23&l=

George

==============================================================================
TOPIC: Spam from gmail (Was: fascism)
http://groups.google.com/group/comp.lang.python/t/6635d24df3ece879?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Feb 23 2010 5:38 pm
From: Steven D'Aprano

On Wed, 24 Feb 2010 00:06:09 +0100, Daniel Fetchinson wrote:

>> Hmm. I wonder if all the spam is coming from the NG side. I'll have
>> to look at that. One of the reasons that I stopped reading UseNet over
>> ten years ago was because of the diminishinig S/N ratio. I have always
>> felt that it was a mistake to gateway this group.
>
> And this has to do with python programming in what way?

I think the question of whether or not comp.lang.python is being spammed,
and if so, what we can do about it, is a good question to raise on
comp.lang.python.

Where else do you think it should be discussed?

--
Steven

== 2 of 3 ==
Date: Tues, Feb 23 2010 6:22 pm
From: Lie Ryan

On 02/24/10 12:38, Steven D'Aprano wrote:
> On Wed, 24 Feb 2010 00:06:09 +0100, Daniel Fetchinson wrote:
>
>>> Hmm. I wonder if all the spam is coming from the NG side. I'll have
>>> to look at that. One of the reasons that I stopped reading UseNet over
>>> ten years ago was because of the diminishinig S/N ratio. I have always
>>> felt that it was a mistake to gateway this group.
>>
>> And this has to do with python programming in what way?
>
>
> I think the question of whether or not comp.lang.python is being spammed,
> and if so, what we can do about it, is a good question to raise on
> comp.lang.python.
>
> Where else do you think it should be discussed?

comp.lang.python.spam_prevention_discussion

== 3 of 3 ==
Date: Tues, Feb 23 2010 6:52 pm
From: Robert Kern

On 2010-02-23 20:22 , Lie Ryan wrote:
> On 02/24/10 12:38, Steven D'Aprano wrote:
>> On Wed, 24 Feb 2010 00:06:09 +0100, Daniel Fetchinson wrote:
>>
>>>> Hmm. I wonder if all the spam is coming from the NG side. I'll have
>>>> to look at that. One of the reasons that I stopped reading UseNet over
>>>> ten years ago was because of the diminishinig S/N ratio. I have always
>>>> felt that it was a mistake to gateway this group.
>>>
>>> And this has to do with python programming in what way?
>>
>>
>> I think the question of whether or not comp.lang.python is being spammed,
>> and if so, what we can do about it, is a good question to raise on
>> comp.lang.python.
>>
>> Where else do you think it should be discussed?
>
> comp.lang.python.spam_prevention_discussion

Which doesn't exist and never will. Sorry, but meta-discussions about the group
are typically on-topic for all groups with some few exceptions (e.g.
non-discussion, binary-only groups with associated .d groups, for instance).

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

==============================================================================
TOPIC: Creating variables from dicts
http://groups.google.com/group/comp.lang.python/t/bb1797ffb6fc3bd7?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 23 2010 5:41 pm
From: Steven D'Aprano

On Tue, 23 Feb 2010 15:41:16 -0800, Luis M. González wrote:

> By the way, if you want the variables inside myDict to be free
> variables, you have to add them to the local namespace. The local
> namespace is also a dictionary "locals()". So you can update locals as
> follows:
>
> locals().update( myDictionary )

No you can't. Try it inside a function.

--
Steven

== 2 of 2 ==
Date: Tues, Feb 23 2010 7:47 pm
From: Luis M. González

On Feb 23, 10:41 pm, Steven D'Aprano
<ste...@REMOVE.THIS.cybersource.com.au> wrote:
> On Tue, 23 Feb 2010 15:41:16 -0800, Luis M. González wrote:
> > By the way, if you want the variables inside myDict to be free
> > variables, you have to add them to the local namespace. The local
> > namespace is also a dictionary "locals()". So you can update locals as
> > follows:
>
> > locals().update( myDictionary )
>
> No you can't. Try it inside a function.
>
> --
> Steven

Sure. Inside a function I would use globals() instead.
Although I don't know if it would be a good practice...

Luis

==============================================================================
TOPIC: PAPER PRESENTATIONS AND SEMIMAR TOPICS.
http://groups.google.com/group/comp.lang.python/t/016095b4e71ba1db?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 23 2010 5:50 pm
From: all in one

PAPER PRESENTATIONS AND SEMIMAR TOPICS.
CHECK OUR VAST PAPER PRESENTATIONS AND SEMIMAR TOPICS INCLUDING
PROJECTS FOR FREE AT
http://presentationsandseminars.blogspot.com

==============================================================================
TOPIC: The future of "frozen" types as the number of CPU cores increases
http://groups.google.com/group/comp.lang.python/t/7ef75c20d1be370d?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 23 2010 5:53 pm
From: "ssteinerX@gmail.com"

On Feb 23, 2010, at 8:30 PM, Steven D'Aprano wrote:

> On Tue, 23 Feb 2010 10:35:38 -0800, John Nagle wrote:
>
>> The issue being discussed was scaling Python for CPUs with many cores.
>> With Intel shipping 4 cores/8 hyperthread CPUs, the 6/12 part working,
>> and the 8/16 part coming along, this is more than a theoretical issue.
>
> Have you tried parallelpython?
>
> http://www.parallelpython.com/

I had not, have you used this successfully?

Thanks,

== 2 of 2 ==
Date: Tues, Feb 23 2010 6:21 pm
From: Steven D'Aprano

On Tue, 23 Feb 2010 20:53:37 -0500, ssteinerX@gmail.com wrote:

>> Have you tried parallelpython?
>>
>> http://www.parallelpython.com/
>
> I had not, have you used this successfully?

Not personally, no.

--
Steven

==============================================================================
TOPIC: compiling python question
http://groups.google.com/group/comp.lang.python/t/bf3208bc8356ae64?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 23 2010 6:00 pm
From: Mag Gam

I am trying to compile python with Tk bindings. Do I need to do
anything special for python to detect and enable Tk?

This is mainly for matplotlib's TkAgg. It seems my compiled version of
python isn't finding the module _tkagg

==============================================================================
TOPIC: formatting a number as percentage
http://groups.google.com/group/comp.lang.python/t/cfcdbdeba49f63dc?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 23 2010 6:03 pm
From: Lawrence D'Oliveiro

In message <6819f2f8-7a9e-4ea4-a936-c4e00394bd30@g28g2000yqh.googlegroups.com>, vsoler wrote:

> I'm trying to print .7 as 70%

Just to be perverse:

(lambda x : (lambda s : s[:s.index(".")] + s[s.index(".") + 1:] + "%")("%.2f" % x).lstrip("0"))(.7)

==============================================================================
TOPIC: Verifying My Troublesome Linkage Claim between Python and Win7
http://groups.google.com/group/comp.lang.python/t/ba27d93256f5c275?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Feb 23 2010 6:04 pm
From: aahz@pythoncraft.com (Aahz)

In article <hm0jn4$tnf$1@news.eternal-september.org>,
W. eWatson <wolftracks@invalid.com> wrote:
>
>My claim is that if one creates a program in a folder that reads a file
>in the folder it and then copies it to another folder, it will read the
>data file in the first folder, and not a changed file in the new folder.
>I'd appreciate it if some w7 users could try this, and let me know what
>they find.
>
>My experience is that if one checks the properties of the copied file,
>it will point to the original py file and execute it and not the copy.

I've no time to verify your specific claim and have no readily available
proof for mine, but I've seen similar issues on Win7. AFAIK, this has
nothing to do with Python.
--
Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer

== 2 of 2 ==
Date: Tues, Feb 23 2010 7:53 pm
From: Rick Dooling

On Feb 23, 1:08 pm, Gib Bogle <g.bo...@auckland.no.spam.ac.nz> wrote:

> It isn't useful to respond to a serious question with OS bigotry.

Okay, I'll go with what Aahz said:

> I've seen similar issues on Win7.
> AFAIK, this has nothing to do with Python.

==============================================================================
TOPIC: Is this secure?
http://groups.google.com/group/comp.lang.python/t/ffff2b290db4e811?hl=en
==============================================================================

== 1 of 10 ==
Date: Tues, Feb 23 2010 6:07 pm
From: Steven D'Aprano

On Tue, 23 Feb 2010 15:36:02 +0100, mk wrote:

> Hello,
>
> I need to generate passwords and I think that pseudo-random generator is
> not good enough, frankly. So I wrote this function:
[snip]
> (yes I know that this way generated string will not contain 'z' because
> 99/4 + 97 = 121 which is 'y')

You're worried about the security of the PRNG but then generate a TWO to
FIVE character lowercase password with no digits, punctuation or the
letter 'z'? That's priceless!

Python's PRNG is not suitable for producing cryptographically strong
streams of random bytes, but it is perfectly strong enough for generating
good passwords.

> The question is: is this secure?

No.

You are wasting your time trying to fix something which isn't a problem,
and introducing a much bigger problem instead. You are MUCH MUCH MUCH
better off with a six or ten character password taken from upper and
lowercase letters, plus digits, plus punctuation, than a four digit
password taken from lowercase letters only. Even if the first case has
some subtle statistical deviation from uniformity, and the second is
"truly random" (whatever that means), it doesn't matter.

Nobody is going to crack your password because the password generator is
0.01% more likely to generate a "G" than a "q". But they *will* brute-
force your password if you have a four digit password taken from a-y only.

> That is, can the string generated this
> way be considered truly random?

Define truly random.

--
Steven

== 2 of 10 ==
Date: Tues, Feb 23 2010 6:19 pm
From: Steven D'Aprano

On Tue, 23 Feb 2010 11:19:59 -0800, Paul Rubin wrote:

> mk <mrkafk@gmail.com> writes:
>> I need to generate passwords and I think that pseudo-random generator
>> is not good enough, frankly. So I wrote this function:... The question
>> is: is this secure? That is, can the string generated this way be
>> considered truly random? (I abstract from not-quite-perfect nature of
>> /dev/urandom at the moment; I can always switch to /dev/random which is
>> better)
>
> urandom is fine and the entropy loss from the numeric conversions and
> eliminating 'z' in that code before you get letters out is not too bad.

What?

You're going from a possible alphabet of 62 (excluding punctuation) or 94
(inc punctuation available on an American keyboard) distinct letters down
to 25, and you say that's "not too bad"?

Paul, if you were anyone else, I'd be sneering uncontrollably about now,
but you're not clueless about cryptography, so what have I missed? Why is
reducing the number of distinct letters by more than 50% anything but a
disaster? This makes the task of brute-forcing the password exponentially
easier.

Add the fact that the passwords are so short (as little as two characters
in my tests) and this is about as far from secure as it is possible to be.

--
Steven

== 3 of 10 ==
Date: Tues, Feb 23 2010 6:40 pm
From: Steven D'Aprano

On Tue, 23 Feb 2010 15:36:02 +0100, mk wrote:

> The question is: is this secure? That is, can the string generated this
> way be considered truly random?

Putting aside the philosophical question of what "truly random" means, I
presume you mean that the letters are uniformly distributed. The answer
to that is, they don't like uniformly distributed.

This isn't a sophisticated statistical test, it's the equivalent of a
back-of-the-envelope calculation: I generated 100,000 random strings with
your code, and counted how often each letter appears:

If the letters are uniformly distributed, you would expect all the
numbers to be quite close, but instead they range from 15063 to 25679:

{'a': 15063, 'c': 20105, 'b': 15100, 'e': 25465, 'd': 25458, 'g': 25597,
'f': 25589, 'i': 25045, 'h': 25679, 'k': 22945, 'j': 25531, 'm': 16187,
'l': 16252, 'o': 16076, 'n': 16012, 'q': 16069, 'p': 16119, 's': 16088,
'r': 16087, 'u': 15951, 't': 16081, 'w': 16236, 'v': 15893, 'y': 15834,
'x': 15956}

Eye-balling it, it looks vaguely two-humped, one hump around 15-16K, the
second around 22-25K. Sure enough, here's a quick-and-dirty graph:

a | ***********************************
b | ***********************************
c | ***********************************************
d | ***********************************************************
e | ***********************************************************
f | ************************************************************
g | ************************************************************
h | ************************************************************
i | ***********************************************************
j | ************************************************************
k | ******************************************************
l | **************************************
m | **************************************
n | *************************************
o | **************************************
p | **************************************
q | **************************************
r | **************************************
s | **************************************
t | **************************************
u | *************************************
v | *************************************
w | **************************************
x | *************************************
y | *************************************

The mean of the counts is 19056.72, and the mean deviation is 3992.28.
While none of this is statistically sophisticated, it does indicate to me
that your function is nowhere even close to uniform. It has a very strong
bias.

--
Steven

== 4 of 10 ==
Date: Tues, Feb 23 2010 6:43 pm
From: Steven D'Aprano

On Wed, 24 Feb 2010 02:40:13 +0000, Steven D'Aprano wrote:

> On Tue, 23 Feb 2010 15:36:02 +0100, mk wrote:
>
>> The question is: is this secure? That is, can the string generated this
>> way be considered truly random?
>
> Putting aside the philosophical question of what "truly random" means, I
> presume you mean that the letters are uniformly distributed. The answer
> to that is, they don't like uniformly distributed.

Er, they don't *look* uniformly distributed.

(Of course, being random, perhaps they are and I just got unlucky.)

--
Steven

== 5 of 10 ==
Date: Tues, Feb 23 2010 6:39 pm
From: Paul Rubin

Steven D'Aprano <steven@REMOVE.THIS.cybersource.com.au> writes:
> Paul, if you were anyone else, I'd be sneering uncontrollably about now,
> but you're not clueless about cryptography, so what have I missed? Why is
> reducing the number of distinct letters by more than 50% anything but a
> disaster? This makes the task of brute-forcing the password exponentially
> easier.

Reducing the number of distinct letters by 50% decreases the entropy per
character by 1 bit. That stuff about mixing letters and digits and
funny symbols just makes the password a worse nuisance to remember and
type, for a small gain in entropy that you can compute and make up for.
The main thing you have to make sure is that the min-entropy is
sufficient for your purposes, and it's generally more convenient to do
that by making the password a little bit longer than by imposing
contortions on the person typing it. Ross Anderson's "Security
Engineering" chapter about passwords is worth reading too:

http://www.cl.cam.ac.uk/~rja14/Papers/SE-03.pdf

When I mentioned entropy loss to the OP though, I mostly meant loss from
getting rid of the letter z. The (binary) Shannon entropy of the
uniform probability distribution on 26 letters is 4.7004397 bits; on 25
letters, it's 4.6438561 bits. The difference isn't enough to give an
attacker that much advantage.

I like the diceware approach to passphrase generation and I've been
using it for years. www.diceware.com explains it in detail and the docs
there are quite well-thought-out and informative. Keep in mind that the
entropy needed for an online password (attacker has to make a server
query for every guess, and hopefully gets locked out after n wrong
tries) and an offline one (attacker has something like a hash of the
password and can run a completely offline search) are different.

Here is a program that I use sometimes:

from math import log
dictfile = '/usr/share/dict/words'

def genrandom(nbytes):
with open('/dev/urandom') as f:
return int(f.read(nbytes).encode('hex'), 16)

def main():
wordlist = list(x.strip() for x in open(dictfile) if len(x) < 7)
nwords = len(wordlist)
print "%d words, entropy=%.3f bits/word"% (
nwords, log(nwords, 2))
print '-'.join(wordlist[genrandom(10)%nwords] for i in xrange(6))

main()

== 6 of 10 ==
Date: Tues, Feb 23 2010 6:41 pm
From: Paul Rubin

Steven D'Aprano <steven@REMOVE.THIS.cybersource.com.au> writes:
> Putting aside the philosophical question of what "truly random" means, I
> presume you mean that the letters are uniformly distributed. The answer
> to that is, they don't like uniformly distributed.

That is a good point, the way those letters are generated (through the
decimal conversion stuff), they won't be all that uniform.

== 7 of 10 ==
Date: Tues, Feb 23 2010 6:50 pm
From: Paul Rubin

mk <mrkafk@gmail.com> writes:
>> You might look at the sitewww.diceware.comfor an approach to this,
>> which you can implement with a program. The docs there are pretty
>> thoughtful and may help you understand the relevant issues.
>
> Thanks. But I would also be grateful for indicating what is wrong/ugly
> in my code.

The stuff about converting 4 random bytes to a decimal string and then
peeling off 2 digits at a time is pretty awful, and notice that since
2**32 is 4294967296, in the cases where you get 10 digits, the first
2-digit pair is never higher than 42. There are also some effects on
the lower digits. The total entropy loss probably isn't fatal but as
described, it's ugly.

I'd write your code something like this:

nletters = 5

def randomword(n):
with open('/dev/urandom') as f:
return ''.join([chr(ord('a')+ord(c)%26) for c in f.read(n)])

print randomword(nletters)

I wouldn't rely on a 5 letter combination for a high security
application, but it might be ok for some low security purposes. Two
random 5-letter combinations separated by a hyphen will be much better,
and is probably easier to type than a solid block of 10 letters.

== 8 of 10 ==
Date: Tues, Feb 23 2010 7:09 pm
From: Robert Kern

On 2010-02-23 20:43 , Steven D'Aprano wrote:
> On Wed, 24 Feb 2010 02:40:13 +0000, Steven D'Aprano wrote:
>
>> On Tue, 23 Feb 2010 15:36:02 +0100, mk wrote:
>>
>>> The question is: is this secure? That is, can the string generated this
>>> way be considered truly random?
>>
>> Putting aside the philosophical question of what "truly random" means, I
>> presume you mean that the letters are uniformly distributed. The answer
>> to that is, they don't like uniformly distributed.
>
> Er, they don't *look* uniformly distributed.
>
> (Of course, being random, perhaps they are and I just got unlucky.)

You'd have to be very, *very* unlucky to get a sample of that size so far from
uniformly distributed if the generating process actually were uniform.

Of course, uniformity isn't really necessary. You just need enough entropy in
the distribution (amongst other things like protection of the seed from being
known or guessed). A skewed distribution of characters is perfectly fine
provided that you had enough characters in the password to meet the desired
entropy requirement. A skewed distribution does require more characters to meet
a specified entropy requirement than a uniform distribution, of course.

That said, for a naive strategy like "pick an independent random character,
repeat", you should just use a uniform distribution. It makes the analysis
easier. Worthwhile generators that give skewed distributions usually do so for a
good reason, like generating pronounceable passwords.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

== 9 of 10 ==
Date: Tues, Feb 23 2010 7:41 pm
From: Lie Ryan

On 02/24/10 14:09, Robert Kern wrote:
> On 2010-02-23 20:43 , Steven D'Aprano wrote:
>> On Wed, 24 Feb 2010 02:40:13 +0000, Steven D'Aprano wrote:
>>
>>> On Tue, 23 Feb 2010 15:36:02 +0100, mk wrote:
>>>
>>>> The question is: is this secure? That is, can the string generated this
>>>> way be considered truly random?
>>>
>>> Putting aside the philosophical question of what "truly random" means, I
>>> presume you mean that the letters are uniformly distributed. The answer
>>> to that is, they don't like uniformly distributed.
>>
>> Er, they don't *look* uniformly distributed.
>>
>> (Of course, being random, perhaps they are and I just got unlucky.)
>
> You'd have to be very, *very* unlucky to get a sample of that size so
> far from uniformly distributed if the generating process actually were
> uniform.
>
> Of course, uniformity isn't really necessary. You just need enough
> entropy in the distribution (amongst other things like protection of the
> seed from being known or guessed). A skewed distribution of characters
> is perfectly fine provided that you had enough characters in the
> password to meet the desired entropy requirement. A skewed distribution
> does require more characters to meet a specified entropy requirement
> than a uniform distribution, of course.
>
> That said, for a naive strategy like "pick an independent random
> character, repeat", you should just use a uniform distribution. It makes
> the analysis easier. Worthwhile generators that give skewed
> distributions usually do so for a good reason, like generating
> pronounceable passwords.

If an attacker knows the that the random number generator have an
extreme skew and he knows the distribution of the letters, how much
advantage would it give the attacker? My initial guess is that the more
skewed the letters are, the better the advantage, since an attacker
using brute-force can write his program to prefer the most likely letters?

== 10 of 10 ==
Date: Tues, Feb 23 2010 7:51 pm
From: Paul Rubin

Lie Ryan <lie.1296@gmail.com> writes:
> If an attacker knows the that the random number generator have an
> extreme skew and he knows the distribution of the letters, how much
> advantage would it give the attacker? My initial guess is that the more
> skewed the letters are, the better the advantage, since an attacker
> using brute-force can write his program to prefer the most likely letters?

A useable (conservative) estimate is that the attacker's workload is 1/p
where p is the probability of the most likely password. That basically
says the password strength can be measured by the min-entropy.
Cryptographers often use that approach. If you want to be more precise,
you can do a conditional probability calculation assuming the attacker
works down the list of possible passwords in order of decreasing
probability, stopping when they hit the right one.

More generally still, passwords regardless of their entropy content are
a sucky way to encapsulate cryptographic secrets. We keep using them
because every alternative has drawbacks of its own.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en

To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Tuesday, February 23, 2010

comp.lang.python - 25 new messages in 10 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts