New Forum: BulletProof, Bitmap Steganography, XOR
in [Cryptography]
|
Prev: New Forum: BulletProof, Bitmap Steganography, XOR
Next: The Winds of Change - The Three Faces of Cryptography.
From: jmorton123 on 11 Jun 2010 22:04 Okay, I haven't heard from anyone that has a problem with the theoretical security of BulletProof Random Binary Number Generator. This is above all the crucial question and there has been ample time to comment on it and no one has been able to offer one iota of a credible argument against it yet many have made several posts completely avoiding this point. And it is all there, mostly in the Help file called, The Grand Theory. But I suggest reading the entire Help files for the most complete explanation for achieving the most security with BulletProof. There are several tools in there to generate the most secure random binary numbers. Like a professor used to say, "You got it: don't forget it." I'm not trying to sell anything. Happy cryptanalysizing! JM On Jun 11, 3:49 pm, rossum <rossu...(a)coldmail.com> wrote: > On Fri, 11 Jun 2010 09:23:35 -0700 (PDT), jmorton123 > > <jmorton...(a)rock.com> wrote: > >There is no source code because it takes work to write these programs > >and I am not going to do someone else's work for them. > > This is crypto. Either we trust you or we have to have the source > code and compile it oourselves. We don't trust you because you are > just a name on usenet. > > No source, no sale. > > rossum
From: Joseph Ashwood on 12 Jun 2010 02:05 "Mr. B" <not(a)supplied.com> wrote in message news:huua1o$sb5$1(a)speranza.aioe.org... > "Although the random number generation process can be described > mathematically, it does not use any mathematical formulas to generate the > random numbers. All the processes are unbiased and require true random > user > input: the key. The only way to reproduce the random numbers without the > key > is by brute-force trial and error." > > A PRNG that involves no mathematics? Good catch. Now I remember this fool. He's unable to grasp the simple fact that a computer is a mathematic device, and if it runs on a computer it is math. No other analysis is necessary, the source is worthless. I should've guessed when he agreed with my commentary that stopped just short of directly calling him an idiot. Joe
From: Bryan on 12 Jun 2010 05:11 jmorton123 wrote: > Let me first say that I am not perfect. I used to think I was until I [...] > I'm sure under the FOIA you could contact these two agencies and they [...] > > You could also contact ARCO which is now BP. I [...] > Try Microsoft as well. They took a look around then. No, no. All I'm asking is for some district keywords so I can Google up the posts you noted. > I'd sure like to hear some constructive criticism of the current > freeware version's security and not so much about who I am and the > implementation and other off-topic issues. *You* brought up these posts of a decade ago. I just want to know how find them. -- --Bryan
From: rossum on 12 Jun 2010 09:09 On Fri, 11 Jun 2010 19:04:09 -0700 (PDT), jmorton123 <jmorton123(a)rock.com> wrote: >Okay, I haven't heard from anyone that has a problem with the >theoretical security of BulletProof Random Binary Number Generator. I am not interested in the theoretical security. I am interested in the practical security. Have you put in a trapdoor that you are not telling us about? Are you sending copie of the random numbers produced back to your website? Have you got a key-logger hidden in the (large) binary? >This is above all the crucial question and there has been ample time >to comment on it and no one has been able to offer one iota of a >credible argument against it yet many have made several posts >completely avoiding this point. So you say, but you are not unbiased. If you did have a key-logger or whatever hidden in your software you are hardly going to announce it on your site, are you. There are plenty of known ways to generate good random numbers without taking the risk of runing an unknown binary downloaded from the net. rossum >And it is all there, mostly in the >Help file called, The Grand Theory. But I suggest reading the entire >Help files for the most complete explanation for achieving the most >security with BulletProof. There are several tools in there to >generate the most secure random binary numbers. > >Like a professor used to say, "You got it: don't forget it." > >I'm not trying to sell anything. > >Happy cryptanalysizing! > >JM > > > >On Jun 11, 3:49 pm, rossum <rossu...(a)coldmail.com> wrote: >> On Fri, 11 Jun 2010 09:23:35 -0700 (PDT), jmorton123 >> >> <jmorton...(a)rock.com> wrote: >> >There is no source code because it takes work to write these programs >> >and I am not going to do someone else's work for them. >> >> This is crypto. Either we trust you or we have to have the source >> code and compile it oourselves. We don't trust you because you are >> just a name on usenet. >> >> No source, no sale. >> >> rossum
From: Bryan on 12 Jun 2010 15:21
jmorton123 wrote: > It reads into 175MB chunks so it does not have to access the hard > drive or hard drives byte by byte in repetitive read operations adding > to the wear and tear to your hard drive. Imagine a read write > operation involving three files accessing one hard drive. This way > the equipment is less taxed. Of course the OS does not access the > hardware byte by byte but doing it this way does minimize the access > operations. Efficient sequential reading does not require large buffers. The tradition technique is to read two modestly-sized buffers ahead of the computation. As long as the computation out-runs the I/O, there's always at least one outstanding sequential read and thus no superfluous disk access. Today, application code needn't worry about that. Modern operating systems detect sequential reading patterns, and initiate reads from disk to memory buffers speculatively, before the application makes the request. The reason for user-space buffering is to minimize system- calls, not disk accesses. > 175MB x 2 = 350MB is chosen because some users have limited RAM and I > want the program to run on as many computer configurations as > possible. Tom's point was that those reads are too big, and he's right. On a net- book with typical apps running, two 175MB buffers could easily exhaust physical memory and force paging from RAM to disk, making it much worse than useless in terms of efficiency and wear on the disk. (A decade or so from now, we'll probably laugh at a 175MB reading being called "large", but we live in the now.) So what's the optimal file I/O size? Not worth figuring. There's a wide range that's not far off the optimal, today somewhere in, say, 4 KB to 1 MB. The popular programming languages offer libraries that do sensibly- sized reads from the OS, and buffer in user space. The app can call the library for reads of whatever size it finds convenient, and the library will make reasonably-efficient system-calls behind the scenes. -- --Bryan Olson |