Peter Jeremy wrote:
On Sun, Jun 11, 2000 at 02:41:12AM +1000, Daniel C. Sobral wrote:
Mind you, shells don't have problems with any character at all in a
filename if they are properly written, but if you are expecting the
filenames generated by mktemp() to be handled by shell, they ought to
As one of the proponents of the change, my apologies for not taking
part in this thread earlier - I am way behind in my reading of most of
the lists.
On Thu, Jun 08, 2000 at 11:11:42AM +1000, Kris Kennaway wrote:
Instead of using only alphabetic characters, the patch uses the following
character
On Sun, 18 Jun 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] "Jeroen C. van Gelderen" writes:
: Pseudo random numbers are so cheap (or they should be) that you
: just don't want to try and 'optimize' here. It is much better to
: be conservative and use a good PRNG until it *proves*
On Sun, 11 Jun 2000, Matthew Dillon wrote:
There's reasonable, and there's overkill. mktemp() has no business
using punctuation in the temporary file names.
:You guys are responding to old messages..I've already changed my mind
:about this.
Kris
--
In God we Trust -- all others
Think about it. If you mix a random number with a non-random number,
using xor, what you get is a random number. It's neither stronger
nor weaker.
No, you'll get weaker random number, it badly affects random distribution.
OR or AND will affect more. What you say is
If it not weakers I can't see why it strenghthens.
I.e. you can constantly strenghthens generator with passing it through XOR -1
?
If not, why any other value is better than -1?
Huh? -1 is a constant, not random. Pass your data through _random_ bits,
XORing it with them, and you have
BTW, if they have the same bits number,
there is no reason to XOR random with predictable, random is not become
more random.
But still confirm this.
If the random number is truly random, then you are correct. If there are
attacks on your random number generator, then XORing other stuff
On Sun, Jun 11, 2000 at 09:24:37AM +0200, Mark Murray wrote:
If it not weakers I can't see why it strenghthens.
I.e. you can constantly strenghthens generator with passing it through XOR -1
?
If not, why any other value is better than -1?
Huh? -1 is a constant, not random. Pass your
Huh? -1 is a constant, not random. Pass your data through _random_ bits,
XORing it with them, and you have unbreakable crypto (one-time-pad) if you
make a record of the random bits (the key).
Yes, if passing _random_ through -1 _data_ not makes it strengthens,
passing through
On Wed, 7 Jun 2000, Kris Kennaway wrote:
:This patch was developed by Peter Jeremy and myself and increases the
:number of possible temporary filenames which can be generated by the
:mktemp() family, by more densely encoding the PID and using a larger set
:of characters to randomly pad with.
:
David Scheidt wrote:
On Wed, 7 Jun 2000, Kris Kennaway wrote:
:This patch was developed by Peter Jeremy and myself and increases the
:number of possible temporary filenames which can be generated by the
:mktemp() family, by more densely encoding the PID and using a larger set
:of
On Sun, 11 Jun 2000, Peter Wemm wrote:
These could matter in the light of mktemp(1).
file=`mktemp foo.`
You guys are responding to old messages..I've already changed my mind
about this.
Why 74 characters? Why not 64?
The more characters we have in the sample set the larger the
:You guys are responding to old messages..I've already changed my mind
:about this.
:
: Why 74 characters? Why not 64?
:
:The more characters we have in the sample set the larger the namespace and
:the better the statistical protection afforded by mktemp()
:
:Kris
There's reasonable, and
On Fri, 9 Jun 2000, Kris Kennaway wrote:
dotfiles for example). I don't believe there's such a thing as a lowest
common denominator of file system naming conventions - either a filesystem
can support UFS names (perhaps through a translation later) or it's not
suitable for running FreeBSD
On Fri, Jun 09, 2000 at 11:23:58PM -0700, Andrey A. Chernov wrote:
On Fri, Jun 09, 2000 at 07:37:09PM -0400, Jeroen C. van Gelderen wrote:
Why to XOR true random bits from arc4random() with non-random bits from
getpid()? It only weakens. Better way is just remove any getpid() code and
On Fri, Jun 09, 2000 at 11:23:58PM -0700, Andrey A. Chernov wrote:
would be the way to go: 64^6 = 2^36 possibilities which is nice...
1) Just totally opposite: mixing random with non-random sources you'll get
into collision much faster then with random source only. 2) Yet, of course,
:1) Just totally opposite: mixing random with non-random sources you'll get
:into collision much faster then with random source only. 2) Yet, of course,
:the code handles collisions.
:
:--
:Andrey A. Chernov
:[EMAIL PROTECTED]
Think about it. If you mix a random number with a non-random
Why not just XOR the whole lot into the current ${randomnumber}?
That way, at least the effort of the whole calculation is not wasted
as much.
Why to XOR true random bits from arc4random() with non-random bits from
getpid()? It only weakens. Better way is just remove any getpid() code
Then you will get collisions which you will have to deal with. I am not
familiar with the code but if we can handle collisions nicely then that
would be the way to go: 64^6 = 2^36 possibilities which is nice...
1) Just totally opposite: mixing random with non-random sources you'll get
It's probably better to just get rid of the PID and use randomness
throughout the name than to use 72 characters. 64^6 vs. 2*(72^3) .
I seem to be in the minority on this, but in general I *like* the
idea that the tempfiles include the pid. It's bad because it makes
it easier for an evil-person
Kris Kennaway wrote:
Bad example. Not _all_ filenames but temp. ones only which allows to run
FreeBSD binary in MSDOS FS with MSDOS files.
The point is the same. Files created by FreeBSD binaries during the course
of operation don't conform to an 8.3 monocase naming scheme (think of
Kris Kennaway wrote:
Instead of using only alphabetic characters, the patch uses the following
character set:
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~
which is not believed to cause any problems with shells. The PID is also
Huh? # does not cause
On Sat, 10 Jun 2000, Kris Kennaway wrote:
Given the other replies in this thread I think I'll just remove the PID
stuff altogether and make the temp filename only constructed from
alphanumeric character. The price is that there's a chance of collision
between two programs who mktemp() and
Kris Kennaway wrote:
On Sat, 10 Jun 2000, Kris Kennaway wrote:
Given the other replies in this thread I think I'll just remove the PID
stuff altogether and make the temp filename only constructed from
alphanumeric character. The price is that there's a chance of collision
between two
Kris Kennaway wrote:
On Sat, 10 Jun 2000, Jeroen C. van Gelderen wrote:
Actually, it's not of course a security risk in the new algorithm (this is
mktemp() after all), but it's a potential failure mode which can cause
applications to fail in ways they otherwise wouldn't (with some
On Sat, Jun 10, 2000 at 02:31:23PM -0700, Kris Kennaway wrote:
between two programs who mktemp() and come up with the same random
filename, which is a theoretical security risk (at present only something
with the same PID can come up with a colliding tempfile name) but the
probability is
On Fri, Jun 09, 2000 at 11:53:34PM -0700, Matthew Dillon wrote:
:1) Just totally opposite: mixing random with non-random sources you'll get
:into collision much faster then with random source only. 2) Yet, of course,
:the code handles collisions.
:
:--
:Andrey A. Chernov
:[EMAIL
On Sat, Jun 10, 2000 at 09:13:30AM +0200, Mark Murray wrote:
Well, I tend to agree that it is not weakens random, but I not see any
improvement too.
That is a pretty fundamental theorem of Cryptography. My suggestion
_strengthens_ the random number. All you lose is one bit if it
If it not
On Sat, Jun 10, 2000 at 07:43:06PM -0700, Andrey A. Chernov wrote:
On Sat, Jun 10, 2000 at 09:31:49AM +0200, Mark Murray wrote:
Incorrect. See my other mail; ${RANDOM} xor ${PREDICTABLE} is random.
Only if predictable have the same bits number as random. If not all bits of
random XOR-ed
On Sat, Jun 10, 2000 at 07:36:10PM -0700, Andrey A. Chernov wrote:
On Fri, Jun 09, 2000 at 11:53:34PM -0700, Matthew Dillon wrote:
:1) Just totally opposite: mixing random with non-random sources you'll get
:into collision much faster then with random source only. 2) Yet, of course,
At 12:07 AM -0500 6/9/00, Dan Nelson wrote:
I still suggest not using symbols at all, since I'd like to
be able to quickly remove tempfiles by hand without worrying
if I have to escape # or ^, etc.
Uh, if I understand the update, the '#' is ALREADY used for
this, in the current implementation.
I still suggest not using symbols at all, since I'd like to be able to
quickly remove tempfiles by hand without worrying if I have to escape #
or ^, etc.
Then disable globbing first. (csh et al) "set noglob" or (sh et al) "set -f
noglob".
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
Mark Murray wrote:
What is the purpose of this? It looks hugely wasteful to me. If you
really need a single random bit, it is not good to waste a block of
hard-gained gryptographic randomness; can you not use a pseudo-random
bit-generator?
arc4random() does not consume entropy
On Thu, Jun 08, 2000 at 08:47:36PM -0700, Kris Kennaway wrote:
filesystems. For example, should we limit all FreeBSD file names to 8.3
single-case in case someone wants to run from an old-style MSDOS
partition?
Bad example. Not _all_ filenames but temp. ones only which allows to run
FreeBSD
On Fri, 9 Jun 2000, Andrey A. Chernov wrote:
On Thu, Jun 08, 2000 at 08:47:36PM -0700, Kris Kennaway wrote:
filesystems. For example, should we limit all FreeBSD file names to 8.3
single-case in case someone wants to run from an old-style MSDOS
partition?
Bad example. Not _all_
On Fri, 9 Jun 2000, Kris Kennaway wrote:
The point is the same. Files created by FreeBSD binaries during the course
of operation don't conform to an 8.3 monocase naming scheme (think of
dotfiles for example). I don't believe there's such a thing as a lowest
common denominator of file system
But I repeat myself; are you still intending to use cryptographic security
for one bit? What does that buy you? An attacker will laugh at the waste
of resources that went into a coin-flip :-). Much better is to use something
cheaper like time-of-day XOR 1 whatever.
Pseudo random
On Fri, Jun 09, 2000 at 12:58:27PM -0700, Kris Kennaway wrote:
Bad example. Not _all_ filenames but temp. ones only which allows to run
FreeBSD binary in MSDOS FS with MSDOS files.
The point is the same. Files created by FreeBSD binaries during the course
of operation don't conform to an
On Fri, Jun 09, 2000 at 10:02:44PM +0200, Mark Murray wrote:
But I repeat myself; are you still intending to use cryptographic security
for one bit? What does that buy you? An attacker will laugh at the waste
of resources that went into a coin-flip :-). Much better is to use something
"Andrey A. Chernov" wrote:
On Fri, Jun 09, 2000 at 10:02:44PM +0200, Mark Murray wrote:
But I repeat myself; are you still intending to use cryptographic security
for one bit? What does that buy you? An attacker will laugh at the waste
of resources that went into a coin-flip :-).
Kris Kennaway wrote:
On Fri, 9 Jun 2000, Andrey A. Chernov wrote:
On Thu, Jun 08, 2000 at 08:47:36PM -0700, Kris Kennaway wrote:
filesystems. For example, should we limit all FreeBSD file names to 8.3
single-case in case someone wants to run from an old-style MSDOS
partition?
:
: Instead of using only alphabetic characters, the patch uses the following
: character set:
:
: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~
:
: Symbols '=' and '+' are prohibited in some other filesystems. It
:is possible to avoid using them ?
:
:--
On Thu, 8 Jun 2000, Daniel O'Connor wrote:
doconn On 08-Jun-00 Kris Kennaway wrote:
doconn On Thu, 8 Jun 2000, Boris Popov wrote:
doconn
doconnInstead of using only alphabetic characters, the patch uses the following
doconncharacter set:
doconn
Hi
+ /* Encode the PID (with 1 bit of randomness) into 3 base-64 chars */
+ pid = getpid() | (arc4random() 0x0002);
What is the purpose of this? It looks hugely wasteful to me. If you
really need a single random bit, it is not good to waste a block of
hard-gained gryptographic
On Thu, 8 Jun 2000, Mark Murray wrote:
Hi
+ /* Encode the PID (with 1 bit of randomness) into 3 base-64 chars */
+ pid = getpid() | (arc4random() 0x0002);
What is the purpose of this? It looks hugely wasteful to me. If you
really need a single random bit, it is not good to
-On [2608 03:12], Kris Kennaway ([EMAIL PROTECTED]) wrote:
Instead of using only alphabetic characters, the patch uses the following
character set:
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~
which is not believed to cause any problems with shells. The PID is
On 8/06, Jeroen Ruigrok van der Werven wrote:
| -On [2608 03:12], Kris Kennaway ([EMAIL PROTECTED]) wrote:
| Instead of using only alphabetic characters, the patch uses the following
| character set:
|
| 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~
|
| which
On Wed, 7 Jun 2000, Kris Kennaway wrote:
Instead of using only alphabetic characters, the patch uses the following
character set:
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~
which is not believed to cause any problems with shells. The PID is also
I think
On Thu, Jun 08, 2000 at 09:50:48PM +1000, Bruce Evans wrote:
I think it should use only letters and digits. For 6 X's, this gives a
namespace of size 52^6 provided the namespace is not gratuitously (?)
reduced using the pid.
Best variant will be to keep the name MSDOS FS 8.3 name safe.
Why
What is the purpose of this? It looks hugely wasteful to me. If you
really need a single random bit, it is not good to waste a block of
hard-gained gryptographic randomness; can you not use a pseudo-random
bit-generator?
arc4random() does not consume entropy except the first time it is
| which is not believed to cause any problems with shells. The PID is also
| Some shells parse # as a deletion character if memory serves me right.
Also ^ is used for substitutions in many shells (as in ^faulty^ok).
Why would you care if some shell used the a character in some special way?
In the last episode (Jun 08), John LoVerso said:
Symbols '=' and '+' are prohibited in some other filesystems.
Specific examples of filesystems supported by FreeBSD and likely used
by programs invoking mktemp(), please! (I'm not sure that the
NetWare filesystem counts!)
But why wouldn't
On Thu, 8 Jun 2000, John LoVerso wrote:
Symbols '=' and '+' are prohibited in some other filesystems.
Specific examples of filesystems supported by FreeBSD and likely used by
programs invoking mktemp(), please! (I'm not sure that the NetWare filesystem
counts!)
Count both, nwfs
On Fri, 9 Jun 2000, Boris Popov wrote:
Count both, nwfs and smbfs, because any program can attempt to
create temporary file on these filesystems. File with an invalid file name
will be rejected, and this will cost an additional lookup operation(s).
I'm not sure that weird filesystems
At 8:47 PM -0700 6/8/00, Kris Kennaway wrote:
On Fri, 9 Jun 2000, Boris Popov wrote:
Count both, nwfs and smbfs, because any program can
attempt to create temporary file on these filesystems. Files
with an invalid file name will be rejected, and this will
cost an additional lookup
In the last episode (Jun 08), Kris Kennaway said:
On Fri, 9 Jun 2000, Boris Popov wrote:
Count both, nwfs and smbfs, because any program can attempt to
create temporary file on these filesystems. File with an invalid
file name will be rejected, and this will cost an additional lookup
On Wed, 7 Jun 2000, Kris Kennaway wrote:
This patch was developed by Peter Jeremy and myself and increases the
number of possible temporary filenames which can be generated by the
mktemp() family, by more densely encoding the PID and using a larger set
of characters to randomly pad with.
On Thu, 8 Jun 2000, Boris Popov wrote:
Instead of using only alphabetic characters, the patch uses the following
character set:
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~
Symbols '=' and '+' are prohibited in some other filesystems. It
is
On 08-Jun-00 Kris Kennaway wrote:
On Thu, 8 Jun 2000, Boris Popov wrote:
Instead of using only alphabetic characters, the patch uses the following
character set:
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz@#%^-_=+:,.~
Symbols '=' and '+' are
59 matches
Mail list logo
