From: jmorton123 on
Just a minor point: there is no PRNG in the program. It does require
a Digits.txt file, the one size fits all file length would contain a
10,000,000 digit string of random digits, and from this the Stego
program merely takes an appropriate digit string long enough to make
an integer of sufficient length to cover the entire range of the image
data bytes available. But the user can supply a Digits.txt file from
any source they choose. I think BulletProof is an excellent source
for generating such a file but others may like some other source for
their random digits. But the file must be called, Digits.txt.

The extractor knows where the randomly chosen bytes are by using the
same Digits.txt file. The required input to extract the embedded
source file is the embedded bitmap image file and the Digits.txt
file. That's all.

(I realize you may have been just making a rhetorical question to the
Shen post.)

JM

On Jun 12, 10:05 am, gordonb.9d...(a)burditt.org (Gordon Burditt) wrote:
> >If you could modify your bitmap stego to enable a user to specify
> >exactly where he wants the LSB to be conform to the stego bits,
> >then you would have done a nice job for the practice. Forget anything
> >else, I would suggest.
>
> Why is this desirable?  Don't you trust the internal PRNG in the
> program, or think you have a better one?  Or is there another reason
> for asking for this?
>
> How does the decrypter know where the bits containing the message
> are, in any given message?

From: jmorton123 on
I hear you and will take another look at my code to reconsider.

JM

On Jun 12, 6:09 am, rossum <rossu...(a)coldmail.com> wrote:
> On Fri, 11 Jun 2010 19:04:09 -0700 (PDT), jmorton123
>
> <jmorton...(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- Hide quoted text -
>
> - Show quoted text -

From: jmorton123 on
From the compiled code you can prove that the software does exactly
what it is described to do. But you have a point about being wary
that it might do something more than what it is described to do.

1.) in the Help files tutorial called, The Mother of All Tutorials,
there are step by step instructions on exactly how to go about this
where the input is controlled by the user and verified to the user
where they can see it with their own two eyes and then the output is
made readable and available to the user so they can verify it with
their own two eyes. In the Additional Utility Programs you can also
generate test files and use these as input for these procedures. Once
you see how this is done you could also create your own test files and
test the software in a similar manner.

2.) Although I have been lax in consistently using this technique
myself although I do have the software installed, the first thing
everyone should do when they get a new system and get it working just
perfectly is to take a disk image of it. I also try to never put
anything on my system that could compromise me, as well. Then I don't
care if I get a virus or key logger or etc. because I just reformat
the HD and place my original disk image back on my computer.

Am I still vulnerable or is this a fool-proof security procedure?

I was thinking about taking a disk image of my laptop. Then getting
another hard drive. Swapping hard drives and restoring the image to
this second hard drive. Then I can just quickly swap out one hard
drive for the other when necessary: one for surfing the risky haunts
of the net and one for conducting serious personal business on the
net.

I highly recommend Acronis True Image. They also have support that
will bend over backwards to solve any problems you might have, even if
the kind of help you need is not guaranteed with your purchase. They
are really great guys. I think they are computer geniuses and this is
their personal company: they really care about the customer. You can
feel it.

JM


On Jun 13, 6:36 am, Tom St Denis <t...(a)iahu.ca> wrote:
> On Jun 11, 10:04 pm, jmorton123 <jmorton...(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 personally don't care about the security of your application.  Aside
> from the fact that I don't run Windows anywhere I just don't have need
> for this class of application.
>
> That said, from the compiled code we can't verify that your
> application actually does what you claim it does [and nothing more].
>
> Tom

From: Tom St Denis on
On Jun 13, 10:28 am, jmorton123 <jmorton...(a)rock.com> wrote:
> From the compiled code you can prove that the software does exactly
> what it is described to do.  But you have a point about being wary
> that it might do something more than what it is described to do.

Actually no I can't. What if your program does as you describe AND
MORE?

> 1.)  in the Help files tutorial called, The Mother of All Tutorials,
> there are step by step instructions on exactly how to go about this
> where the input is controlled by the user and verified to the user
> where they can see it with their own two eyes and then the output is
> made readable and available to the user so they can verify it with
> their own two eyes.  In the Additional Utility Programs you can also
> generate test files and use these as input for these procedures.  Once
> you see how this is done you could also create your own test files and
> test the software in a similar manner.

Or, you could provide source code for peer review and be done with.

<snip>

Questions you have to answer yourself are

1. Do you see a market for your tools, if so how large
2. If you don't plan on opening the source code, how do you really
plan to vet the software, seeing as nobody has any reason to trust you
3. Why is your XOR program 1.2MB in size?

Tom
From: rossum on
On Sun, 13 Jun 2010 06:39:01 -0700 (PDT), jmorton123
<jmorton123(a)rock.com> wrote:

>Just a minor point: there is no PRNG in the program. It does require
>a Digits.txt file, the one size fits all file length would contain a
>10,000,000 digit string of random digits, and from this the Stego
>program merely takes an appropriate digit string long enough to make
>an integer of sufficient length to cover the entire range of the image
>data bytes available. But the user can supply a Digits.txt file from
>any source they choose. I think BulletProof is an excellent source
>for generating such a file but others may like some other source for
>their random digits. But the file must be called, Digits.txt.
>
>The extractor knows where the randomly chosen bytes are by using the
>same Digits.txt file. The required input to extract the embedded
>source file is the embedded bitmap image file and the Digits.txt
>file. That's all.
>
>(I realize you may have been just making a rhetorical question to the
>Shen post.)
>
>JM
You really need to read up on the One Time Pad and why it is of little
practical use in many situations. If the program needs a 10 Mdigit
file to decrypt then you need to transmit that 10 Mdigit file
*securely* to the destination. If you can do that then why not just
use the same secure channel to transmit the actual data?

In effect the 10 Mdigit file is the key and you have a lot of problems
with a key that big.

rossum


>
>On Jun 12, 10:05 am, gordonb.9d...(a)burditt.org (Gordon Burditt) wrote:
>> >If you could modify your bitmap stego to enable a user to specify
>> >exactly where he wants the LSB to be conform to the stego bits,
>> >then you would have done a nice job for the practice. Forget anything
>> >else, I would suggest.
>>
>> Why is this desirable?  Don't you trust the internal PRNG in the
>> program, or think you have a better one?  Or is there another reason
>> for asking for this?
>>
>> How does the decrypter know where the bits containing the message
>> are, in any given message?