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: Mr. B on 13 Jun 2010 14:48 > Yet people usually talk about shuffling cards and throwing dice, plain > and simple, especially when it most accurately describes the action. Not when we are dealing with cryptography -- we want provable security, which means mathematics. > There is good reason the bible admonishes those that would call > another man a fool. The bible has nothing to do with cryptography. > Can you offer us any constructive criticism regarding the theory > presented in the BulletProof Help file called, The Grand Theory? Where is that file? I am not going to run some executable file, even if it is just an installer, just because you ask me to. Post the documentation here in this newsgroup or on your website, or else you will get no feedback from me. Speaking of things posted on your website, please explain your claim that your random number generator is more secure that Blum Blum Shub because it has no limit key size (a property Blum Blum Shub also has). -- B
From: Maaartin on 13 Jun 2010 15:04 On Jun 13, 1:37 am, Maaartin <grajc...(a)seznam.cz> wrote: I re-ran my simple benchmark concentrating on the most-promising sizes: blocksize seconds 4096 284 8192 186 16384 140 32768 135 65536 135 131072 135 262144 135 524288 135 1048576 243 This clearly shows that any buffer size between 16 and 512 kB is fine, and that using larger buffers is a clear non-sense. > It clearly shows that sizes above about 1MB makes it slower because of > the cache, I'm not sure what happens at the small sizes (as the system > calls made by Java are independent of the size since everything goes > through File.read() returning a single byte). I was wrong, it runs through File.read(byte[] buffer, int off, int length) giving length bytes at once. I think we can ignore the overhead of Java and state, that the using too small buffer sizes is bad because of the OS(*) not being able to handle it as efficiently as it should. The performance for large buffer sizes diminishes because of the L2 cache misses (it's size is 1MB on my computer, which corresponds with the huge speed loss when switching from 0.5MB to 1MB buffers). There may be other reasons, too. It would be nice if somebody could try it using another language/ computer/OS. (*) I mean Windows XP 64, some could argue against calling it OS.
From: Bryan on 13 Jun 2010 15:19 jmorton123, A.K.A. jjanes, A.K.A. Anthony Stephen Szopa wrote: [ rossum had written: >> 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? ] > Nor would it do any good to tell you here that I have done no such > thing: nevertheless, what I've described is all that there is to the > freeware. And we're supposed to take your word for anything after the stuff you've tried to pull here? http://groups.google.com/group/sci.crypt/browse_frm/thread/32908584bd68ea62 -- --Bryan
From: Earl_Colby_Pottinger on 14 Jun 2010 01:08 On Jun 13, 2:04 pm, Maaartin <grajc...(a)seznam.cz> wrote: > On Jun 13, 1:37 am, Maaartin <grajc...(a)seznam.cz> wrote: > > I re-ran my simple benchmark concentrating on the most-promising > sizes: > > blocksize seconds > 4096 284 > 8192 186 > 16384 140 > 32768 135 > 65536 135 > 131072 135 > 262144 135 > 524288 135 > 1048576 243 > > This clearly shows that any buffer size between 16 and 512 kB is fine, > and that using larger buffers is a clear non-sense. > > > It clearly shows that sizes above about 1MB makes it slower because of > > the cache, I'm not sure what happens at the small sizes (as the system > > calls made by Java are independent of the size since everything goes > > through File.read() returning a single byte). > > I was wrong, it runs through File.read(byte[] buffer, int off, int > length) giving length bytes at once. I think we can ignore the > overhead of Java and state, that the using too small buffer sizes is > bad because of the OS(*) not being able to handle it as efficiently as > it should. > > The performance for large buffer sizes diminishes because of the L2 > cache misses (it's size is 1MB on my computer, which corresponds with > the huge speed loss when switching from 0.5MB to 1MB buffers). There > may be other reasons, too. > > It would be nice if somebody could try it using another language/ > computer/OS. I am using Haiku-OS-A1R2, and to update the OS on the hard drive I use 'DD' to copy a disk image to a drive partition. I noticed the same behavior. DD defaults to 256 byte buffers, the larger the buffers - the faster it runs. Then at about 1.5MB the performance starts to fall, I think this a combination of the cache size (2MB) and the allocator call which now has to zero out the memory locations.
From: Mr. B on 14 Jun 2010 13:39
jmorton123 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. Oh, that's interesting, so you ship a security proof along with that program, so that my automatic verification system can check that the program only does what you claim it does? Where is that proof, exactly? All I saw on your website was a standalone executable installer, compiled for Windows. > 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? You are still vulnerable to viruses that insert themselves into the system BIOS. You also have to double check that you do not have any removable media attached to your system -- viruses can hide there too. A virus might also insert itself into firmware on various devices you connect to your system. The better security practice is not to execute code that people on Usenet ask you to execute, unless you can verify that it does precisely what they claim it does -- which requires either source code or some sort of verification scheme, neither of which you have provided. > I highly recommend Acronis True Image. Or, you can use dd, which ships with every operating system except the one that you compiled your programs for. -- B |