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 o
In message <[EMAIL PROTECTED]> Peter Jeremy writes:
: On 2000-Jun-19 12:03:40 +1000, Warner Losh <[EMAIL PROTECTED]> 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 'opti
On 2000-Jun-19 12:03:40 +1000, Warner Losh <[EMAIL PROTECTED]> 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
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 *pr
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* to be very
: problematic.
I disagree with
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
>characte
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 othe
: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 t
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 names
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 char
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.
:
:I
> > 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 1
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
> > 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 othe
> 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 unbrea
> Only if predictable have the same bits number as random. If not all bits of
> random XOR-ed (i.e. half of random), it becomes weaker.
Sigh. Exactly. The other half is _not_random_; I am not talking about it.
> BTW, if they have the same bits number,
> there is no reason to XOR random with pre
> > 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 s
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,
>
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
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 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 (i.e. half of random), it becomes weaker.
BTW, if they have the same bi
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 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 a
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 (
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 very low
> > probability
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
> > b
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
On Fri, 9 Jun 2000, Andrey A. Chernov wrote:
> 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 f
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
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
>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-perso
> > 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'l
> > 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
: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-rando
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,
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 an
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
> > left arc4random() only.
>
> Then you will get collisions which you
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
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
> > > pa
"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 coi
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 some
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
> > 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 r
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 syst
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 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
FreeBS
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 c
> 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 PROTECTE
On Thu, 8 Jun 2000, Kris Kennaway 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 f
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.
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 lo
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
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
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,
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 woul
> | >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?
At 12:51 PM +0200 6/8/00, Samuel Tardieu wrote:
>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:
>| >
>| >0123456789ABCDEFGHIJKLMNOPQRST
> > 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 t
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.
>
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 th
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@#%^-_=+:,.~
| >
| >wh
-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 PI
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 g
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, Daniel O'Connor wrote:
doconn> On 08-Jun-00 Kris Kennaway wrote:
doconn> > On Thu, 8 Jun 2000, Boris Popov wrote:
doconn> >
doconn> > > > Instead of using only alphabetic characters, the patch uses the following
doconn> > > > character set:
doconn> > > >
0123456789ABCDEFGH
:>
:> 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 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
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
>
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.
69 matches
Mail list logo
