Hi,
I have a tool which calls RAND_bytes() for a length of 16 bytes while
using the CAPI engine and having set it to be used for all purposes. If
I run it in my Visual Studio Debugger in executes perfectly, but if run
from within a command shell, it hangs on this statement (I localized it
On 7/25/2012 3:01 PM, Florian Rüchel wrote:
Hi,
I have a tool which calls RAND_bytes() for a length of 16 bytes while
using the CAPI engine and having set it to be used for all purposes.
If I run it in my Visual Studio Debugger in executes perfectly, but if
run from within a command shell,
On Wed 25/07/12 2:16 PM , Jakob Bohm jb-open...@wisemo.com sent:
On 7/25/2012 3:01 PM, Florian Rüchel wrote:
Hi,
I have a tool which calls RAND_bytes() for a length of 16 bytes while
using the CAPI engine and having set it to be used for all purposes.
If I run it in my Visual Studio
Hi,
thanks for your responses. It seems this may actually be a heap
corruption after all, as the following function causes the crash:
`heap_first(hentry,hlist.th32ProcessID,hlist.th32HeapID)` on line 521
with version 1.0.1
I will investigate this further tomorrow and hopefully come up with
is, that the thread has full cpu load from that point on.
If I use a own readline method, this problem doesen't occure. (But it
lacks of performance, because it has to read single chars until LF or
buffer end.)
Has anyone else got the same problem and figured out the reason and/or a
solution
I have a similar question: By how much does encryption
with standard encryption algorythms (3DES, RC4, etc.) increase
the size of a large file I'm transmitting? If I am transferring
an already compressed 1 MB file, for example, using say 3DES,
is there a significant bandwidth hit or does
The result file will be nearly the same size as the original... In fact,
it will be rounded to the nearest bigger multiple of the cipher block
size. For example, if you use 3DES, the block size is 8 bytes, your
ciphered file will be rounded to the next multiple of 8 bytes (if it's
already a
