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
> "Dan" == Dan Moschuk <[EMAIL PROTECTED]> writes:
Dan> I've avoided this conversation, but what would everyone think of
Dan> a tmpfs type of solution with a security minded design? I took a
Dan> brief look at phk's md driver, and it could be quite easily
Dan> molded to do what I want to do.
| >
| > Maybe the soltion is to think out of the box. Maybe temporary
| > filestore should be a more official OS service. Race conditions would
| > be far less common if the OS itself was managing the namespace.
| >
| > You might even expand the capability somewhat. Provide process local,
|
David Gilbert wrote:
>
> Maybe the soltion is to think out of the box. Maybe temporary
> filestore should be a more official OS service. Race conditions would
> be far less common if the OS itself was managing the namespace.
>
> You might even expand the capability somewhat. Provide process l
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
Maybe the soltion is to think out of the box. Maybe temporary
filestore should be a more official OS service. Race conditions would
be far less common if the OS itself was managing the namespace.
You might even expand the capability somewhat. Provide process local,
uid local and global names
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.
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.
Instead of using only alphabetic characters, the
74 matches
Mail list logo
