Re: [cryptopp-users] Re: Strange behavior with -static compilation flag

[Arik Agazarian]

We Need wallet address of 7 months for clean transactions, traceable on
Blockchain,
Ratio 45%/45%/10%
Sender/Reciever/Mandate
Telegram sender: @Arik_loader


On Thu, Nov 2, 2023, 7:28 PM Catherine Issabel 
wrote:

>
> $500 million dollars available only for good and trusted receiver or
> mandate
> Kindly contact the sender for more information:+1 (336) 345-9681
> On Thursday, April 27, 2023 at 5:54:52 AM UTC+1 Jeffrey Walton wrote:
>
>> On Thu, Apr 27, 2023 at 12:19 AM Dwight Kulkarni 
>> wrote:
>> >
>> > Your code is exactly what I had before. But I was getting that heap
>> error. It only went away when I used NEW. I have never seen that before. I
>> also don't like using NEW at all but it wasn't working.
>>
>> convert_cryptopp_intege and convert_cryptopp_integer_str test fine for
>> the attached program. You have a problem somewhere else in your
>> program.
>>
>> $ g++ -o test.exe -g3 -O1 -fsanitize=address test.cxx ./libcryptopp.a
>> $ ./test.exe
>> Iostream: e9e930805f30e3ac95845917bef1d708h
>> Vector: e9e930805f30e3ac95845917bef1d708
>> Convert1: e9e930805f30e3ac95845917bef1d708
>> Convert2: e9e930805f30e3ac95845917bef1d708
>>
>> Jeff
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Crypto++ Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cryptopp-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/cryptopp-users/2eb52212-320f-4f5c-92da-6c61f95325c5n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/CAOLESwkKjr%2B_c1yrtHpJjCPphCK-RKaPpjL-k3T7in87gKOGqg%40mail.gmail.com.

Re: [cryptopp-users] Re: Strange behavior with -static compilation flag

[Catherine Issabel]

$500 million dollars available only for good and trusted receiver or 
mandate 
Kindly contact the sender for more information:+1 (336) 345-9681
On Thursday, April 27, 2023 at 5:54:52 AM UTC+1 Jeffrey Walton wrote:

> On Thu, Apr 27, 2023 at 12:19 AM Dwight Kulkarni  
> wrote:
> >
> > Your code is exactly what I had before. But I was getting that heap 
> error. It only went away when I used NEW. I have never seen that before. I 
> also don't like using NEW at all but it wasn't working.
>
> convert_cryptopp_intege and convert_cryptopp_integer_str test fine for
> the attached program. You have a problem somewhere else in your
> program.
>
> $ g++ -o test.exe -g3 -O1 -fsanitize=address test.cxx ./libcryptopp.a
> $ ./test.exe
> Iostream: e9e930805f30e3ac95845917bef1d708h
> Vector: e9e930805f30e3ac95845917bef1d708
> Convert1: e9e930805f30e3ac95845917bef1d708
> Convert2: e9e930805f30e3ac95845917bef1d708
>
> Jeff
>

-- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/2eb52212-320f-4f5c-92da-6c61f95325c5n%40googlegroups.com.

Re: [cryptopp-users] Re: Strange behavior with -static compilation flag

[Jeffrey Walton]

On Thu, Apr 27, 2023 at 12:19 AM Dwight Kulkarni  wrote:
>
> Your code is exactly what I had before. But I was getting that heap error. It 
> only went away when I used NEW. I have never seen that before. I also don't 
> like using NEW at all but it wasn't working.

convert_cryptopp_intege and convert_cryptopp_integer_str test fine for
the attached program. You have a problem somewhere else in your
program.

$ g++ -o test.exe -g3 -O1 -fsanitize=address test.cxx ./libcryptopp.a
$ ./test.exe
Iostream: e9e930805f30e3ac95845917bef1d708h
  Vector: e9e930805f30e3ac95845917bef1d708
Convert1: e9e930805f30e3ac95845917bef1d708
Convert2: e9e930805f30e3ac95845917bef1d708

Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/CAH8yC8%3D_bzpPrTJZTmMGqjGF1deScu-rvuO%2BX4%2Bw3ne2pVC0zA%40mail.gmail.com.
#include 
#include 
#include "integer.h"
#include "osrng.h"

std::string convert_cryptopp_integer_str(const CryptoPP::Integer& n)
{
using namespace CryptoPP;

const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
std::string v; v.resize(len);

n.Encode((byte*)[0], v.size(), Integer::UNSIGNED);
return v;

}

std::vector convert_cryptopp_integer(const CryptoPP::Integer& n)
{
using namespace CryptoPP;

const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
std::vector v(len);

n.Encode((byte*)[0], v.size(), Integer::UNSIGNED);
return v; 
}

int main(int argc, char* argv[])
{
using namespace CryptoPP;

AutoSeededRandomPool prng;
Integer n;

n.Randomize(prng, 128);
const size_t len = n.MinEncodedSize(Integer::UNSIGNED);

// Error in vector size
std::vector v(len);
n.Encode((byte*)[0], v.size(), Integer::UNSIGNED);

std::cout << "Iostream: " << std::hex << n << std::endl;
std::cout << "  Vector: ";
for(byte i : v) {
  std::cout << std::hex << std::setw(2) << std::setfill('0') << (i & 0xff);
}
std::cout << std::endl;

std::cout << "Convert1: ";
std::string w = convert_cryptopp_integer_str(n);
for(byte i : w) {
  std::cout << std::hex << std::setw(2) << std::setfill('0') << (i & 0xff);
}
std::cout << std::endl;

std::cout << "Convert2: ";
std::vector x = convert_cryptopp_integer(n);
for(byte i : x) {
  std::cout << std::hex << std::setw(2) << std::setfill('0') << (i & 0xff);
}
std::cout << std::endl;

return 0;
}

Re: [cryptopp-users] Re: Strange behavior with -static compilation flag

[Jeffrey Walton]

On Thu, Apr 27, 2023 at 12:19 AM Dwight Kulkarni  wrote:
>
> Your code is exactly what I had before. But I was getting that heap error. It 
> only went away when I used NEW. I have never seen that before. I also don't 
> like using NEW at all but it wasn't working.
>

When moving an allocation from the stack to the heap (using new), and
behavior changes (like no memory error), it indicates a memory error.
The problem existed before and after. The heap just masked it.

Go back to your original program, and use Address Sanitizer on it. It
will show you where the error is, or give you a toe hold into the
problem.

Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/CAH8yC8nQqZCewJuHOWMF30j%3DAvbJ26vuBMjJDyF86nA_%2BjkNbw%40mail.gmail.com.

Re: [cryptopp-users] Re: Strange behavior with -static compilation flag

[Dwight Kulkarni]

Hi Jeff,

Your code is exactly what I had before. But I was getting that heap error. 
It only went away when I used NEW. I have never seen that before. I also 
don't like using NEW at all but it wasn't working. 

On Wednesday, April 26, 2023 at 11:21:46 PM UTC-4 Jeffrey Walton wrote:

> On Wed, Apr 26, 2023 at 11:16 PM Jeffrey Walton  wrote:
> >
> > On Wed, Apr 26, 2023 at 6:13 PM Dwight Kulkarni  
> wrote:
> > >
> > > I ran address sanitizer: Heap use after free is the problem. I had to 
> use the NEW operator to allocate the ram. What is weird is that usually it 
> will error out right away after it goes out of scope, but this was delayed 
> in recovering the memory, so it was working and then poof the memory 
> disappears, but there is no access violation, it just returns bad result 
> but only sometimes. Other times it is working and if there is a delay then 
> the RAM gets reclaimed in that time and the error occurs right in the 
> middle of the function. Really freaky.
> > >
> > > char* convert_cryptopp_integer_str(Integer n, size_t& msg_len){
> > > const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
> > > char* v = new char[len];
> > > msg_len = len;
> > > n.Encode((byte*)v, len, Integer::UNSIGNED);
> > > return v;
> > > }
> > >
> > > std::vector* convert_cryptopp_integer(Integer n){
> > > const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
> > > std::vector* v = new std::vector(len);
> > > n.Encode((byte*)v, v->size(), Integer::UNSIGNED);
> > > return v;
> > > }
> >
> > So C-ish... Stop managing allocations with new and free. Let the std
> > C++ library do the work for you:
> >
> > std::string convert_cryptopp_integer_str(const CryptoPP::Integer& n)
> > {
> > using namespace CryptoPP;
> >
> > const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
> > std::string v;
> > v.resize(len);
> >
> > n.Encode((byte*)[0], v.size(), Integer::UNSIGNED);
> > return v;
> >
> > }
> >
> > std::vector convert_cryptopp_integer(const 
> CryptoPP::Integer& n)
> > {
> > using namespace CryptoPP;
> >
> > const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
> > std::vector v(len);
> >
> > n.Encode((byte*)[len], v.size(), Integer::UNSIGNED);
> > return v;
> > }
>
> I probably should have said... This is the _portable_ way to get the
> non-const pointer to the first element in the array:
>
> n.Encode((byte*)[0], v.size(), Integer::UNSIGNED);
>
> It is portable because it works with C++98 and above. Other methods
> exist, but they work with C++11 and above.
>
> This was wrong. It should have used element 0, not element 'len':
>
> n.Encode((byte*)[len], v.size(), Integer::UNSIGNED);
>
> Jeff
>

-- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/eea0b651-b625-4cd6-becf-0308f6cc0efan%40googlegroups.com.

Re: [cryptopp-users] Re: Strange behavior with -static compilation flag

[Jeffrey Walton]

On Wed, Apr 26, 2023 at 11:16 PM Jeffrey Walton  wrote:
>
> On Wed, Apr 26, 2023 at 6:13 PM Dwight Kulkarni  wrote:
> >
> > I ran address sanitizer:  Heap use after free is the problem.  I had to use 
> > the NEW operator to allocate the ram.  What is weird is that usually it 
> > will error out right away after it goes out of scope, but this was delayed 
> > in recovering the memory, so it was working and then poof the memory 
> > disappears, but there is no access violation, it just returns bad result 
> > but only sometimes. Other times it is working and if there is a delay then 
> > the RAM gets reclaimed in that time and the error occurs right in the 
> > middle of the function. Really freaky.
> >
> > char* convert_cryptopp_integer_str(Integer n, size_t& msg_len){
> > const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
> > char* v = new char[len];
> > msg_len = len;
> > n.Encode((byte*)v, len, Integer::UNSIGNED);
> > return v;
> > }
> >
> > std::vector* convert_cryptopp_integer(Integer n){
> > const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
> > std::vector* v = new std::vector(len);
> > n.Encode((byte*)v, v->size(), Integer::UNSIGNED);
> > return v;
> > }
>
> So C-ish... Stop managing allocations with new and free. Let the std
> C++ library do the work for you:
>
> std::string convert_cryptopp_integer_str(const CryptoPP::Integer& n)
> {
> using namespace CryptoPP;
>
> const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
> std::string v;
> v.resize(len);
>
> n.Encode((byte*)[0], v.size(), Integer::UNSIGNED);
> return v;
>
> }
>
> std::vector convert_cryptopp_integer(const CryptoPP::Integer& 
> n)
> {
> using namespace CryptoPP;
>
> const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
> std::vector v(len);
>
> n.Encode((byte*)[len], v.size(), Integer::UNSIGNED);
> return v;
> }

I probably should have said... This is the _portable_ way to get the
non-const pointer to the first element in the array:

n.Encode((byte*)[0], v.size(), Integer::UNSIGNED);

It is portable because it works with C++98 and above. Other methods
exist, but they work with C++11 and above.

This was wrong. It should have used element 0, not element 'len':

n.Encode((byte*)[len], v.size(), Integer::UNSIGNED);

Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/CAH8yC8nzj4itGXwqvbXEVw9w396qJtfyYWb_1--aRny7h6Z3aQ%40mail.gmail.com.

Re: [cryptopp-users] Re: Strange behavior with -static compilation flag

[Jeffrey Walton]

On Wed, Apr 26, 2023 at 6:13 PM Dwight Kulkarni  wrote:
>
> I ran address sanitizer:  Heap use after free is the problem.  I had to use 
> the NEW operator to allocate the ram.  What is weird is that usually it will 
> error out right away after it goes out of scope, but this was delayed in 
> recovering the memory, so it was working and then poof the memory disappears, 
> but there is no access violation, it just returns bad result but only 
> sometimes. Other times it is working and if there is a delay then the RAM 
> gets reclaimed in that time and the error occurs right in the middle of the 
> function. Really freaky.
>
> char* convert_cryptopp_integer_str(Integer n, size_t& msg_len){
> const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
> char* v = new char[len];
> msg_len = len;
> n.Encode((byte*)v, len, Integer::UNSIGNED);
> return v;
> }
>
> std::vector* convert_cryptopp_integer(Integer n){
> const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
> std::vector* v = new std::vector(len);
> n.Encode((byte*)v, v->size(), Integer::UNSIGNED);
> return v;
> }

So C-ish... Stop managing allocations with new and free. Let the std
C++ library do the work for you:

std::string convert_cryptopp_integer_str(const CryptoPP::Integer& n)
{
using namespace CryptoPP;

const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
std::string v;
v.resize(len);

n.Encode((byte*)[0], v.size(), Integer::UNSIGNED);
return v;

}

std::vector convert_cryptopp_integer(const CryptoPP::Integer& n)
{
using namespace CryptoPP;

const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
std::vector v(len);

n.Encode((byte*)[len], v.size(), Integer::UNSIGNED);
return v;
}

Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/CAH8yC8kOB4qrgzPAx7X5OZ4dsrwAU%3D0%2BD%3Dqu7LN3HHDobgT3rw%40mail.gmail.com.

Re: [cryptopp-users] Re: Strange behavior with -static compilation flag

[Dwight Kulkarni]

Hi Jeff,

I ran address sanitizer:  Heap use after free is the problem.  I had to use 
the NEW operator to allocate the ram.  What is weird is that usually it 
will error out right away after it goes out of scope, but this was delayed 
in recovering the memory, so it was working and then poof the memory 
disappears, but there is no access violation, it just returns bad result 
but only sometimes. Other times it is working and if there is a delay then 
the RAM gets reclaimed in that time and the error occurs right in the 
middle of the function. Really freaky.

char* convert_cryptopp_integer_str(Integer n, size_t& msg_len){
const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
char* v = new char[len];
msg_len = len;
n.Encode((byte*)v, len, Integer::UNSIGNED);
return v;
}

std::vector* convert_cryptopp_integer(Integer n){
const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
std::vector* v = new std::vector(len);
n.Encode((byte*)v, v->size(), Integer::UNSIGNED);
return v; 
}




=
==23926==ERROR: AddressSanitizer: heap-use-after-free on address 
0x82607880 at pc 0xca7153cc bp 0xdc752330 sp 0xdc752350
READ of size 1 at 0x82607880 thread T0  
==23926==ABORTING


On Tuesday, April 25, 2023 at 9:21:05 PM UTC-4 Jeffrey Walton wrote:

> On Tue, Apr 25, 2023 at 7:12 PM Dwight Kulkarni  
> wrote:
> >
> > I got it working by implementing the raw Integer method. See my code 
> below, previous encryption is commented out. I don't know why but it wasn't 
> working otherwise and I think it has something to do with memory allocation 
> maybe it works with -static flag because some references are staying in 
> scope as the entire library is loaded into RAM ?
> >
> > I had to implement the PKCS1v15 again but I would like to know what is 
> wrong so I can write the code accordingly.
> >
> > I have the Integer c.
> >
> > 1) If I use snippet 1, get the vector and then read it into a string 
> "res" and return it, this works.
> >
> > 2) If I use snippet 2, aka do the exact same thing in the function. It 
> doesn't work. I am trying to think whether the Vector needs to be declared 
> with new ? I am passing back the whole object not a pointer, so it should 
> not go out of scope ?? But maybe the resarr2 is not a deep copy and when it 
> goes out of scope the string data is also destroyed ?? On the other side, 
> the serve complains with Snippet 2 and not with Snippet 1.
>
> If you want someone to look at your programs, you need to provide a
> minimal reproducer somewhere it can be cloned like GitHub or GitLab.
> I'm not going to try to copy/paste it from the mailing list. I'm also
> not going to try to make it compile due to missing functions and
> missing main().
>
> Now, onto your memory problems. Use Address Sanitizer or Valgrind to
> locate the memory error. I recommend Address Sanitizer (Asan). Asan
> produces the best debug and diagnostics. Follow these steps.
>
> # where the Crypto++ sources are
> cd cryptopp
> make distclean
>
> # make the library
> CXXFLAGS="-DNDEBUG -g3 -O1 -fsanitize=address" make -j 5
>
> # test the library. Notice no memory errors
> ./cryptest.exe vv
>
> # copy your test program. Be sure to name it *.cxx
> cp ../../test.cxx .
> g++ -o test.exe -DNDEBUG -g3 -O1 -I. -fsanitize=address test.cxx 
> ./libcryptopp.a
>
> # run your program
> ./test.exe
>
> Attached is my broken test.cxx. I used a vector that was too small:
>
> size_t len = n.MinEncodedSize(Integer::UNSIGNED);
> std::vector v(len-4);
> n.Encode((byte*)[0], v.size()+4, Integer::UNSIGNED);
>
> Here is the result of my broken test program:
>
> $ g++ -o test.exe -DNDEBUG -g3 -O1 -I. -fsanitize=address test.cxx
> ./libcryptopp.a
> $ ./test.exe
> =
> ==12167==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x6020003c at pc 0x7ffb24239e67 bp 0x7ffd10274f30 sp
> 0x7ffd102746d8
> WRITE of size 1 at 0x6020003c thread T0
> #0 0x7ffb24239e66 in __interceptor_memmove
>
> ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:810
> #1 0x55a0a1c8cac2 in memmove
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:36
> #2 0x55a0a1c8cac2 in CryptoPP::ArraySink::Put2(unsigned char
> const*, unsigned long, int, bool)
> /home/jwalton/cryptopp/filters.cpp:545
> #3 0x55a0a1b1f642 in
> CryptoPP::BufferedTransformation::Put(unsigned char const*, unsigned
> long, bool) /home/jwalton/cryptopp/cryptlib.h:1689
> #4 0x55a0a1b1f642 in
> CryptoPP::BufferedTransformation::Put(unsigned char, bool)
> /home/jwalton/cryptopp/cryptlib.h:1679
> #5 0x55a0a1b1f642 in
> CryptoPP::Integer::Encode(CryptoPP::BufferedTransformation&, unsigned
> long, CryptoPP::Integer::Signedness) const
> /home/jwalton/cryptopp/integer.cpp:3439
> #6 0x55a0a1b1fa84 in CryptoPP::Integer::Encode(unsigned char*,
> unsigned long, CryptoPP::Integer::Signedness) const
> /home/jwalton/cryptopp/integer.cpp:3431
> 

Re: [cryptopp-users] Re: Strange behavior with -static compilation flag

[Dwight Kulkarni]

Hi Jeff,

I ran address sanitizer:  Heap use after free is the problem.  I had to use 
the NEW operator to allocate the ram.  What is weird is that usually it 
will error out right away after it goes out of scope, but this was delayed 
in recovering the memory, so it was working and then poof the memory 
disappears, but there is no access violation, it just returns bad result 
but only sometimes. Other times it is working and if there is a delay then 
the RAM gets reclaimed in that time and the error occurs right in the 
middle of the function. Really freaky.

char* convert_cryptopp_integer_str(Integer n, size_t& msg_len){
const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
char* v = new char[len];
msg_len = len;
n.Encode((byte*)v, len, Integer::UNSIGNED);
return v;
}

std::vector* convert_cryptopp_integer(Integer n){
const size_t len = n.MinEncodedSize(Integer::UNSIGNED);
std::vector* v = new std::vector(len);
n.Encode((byte*)v, v->size(), Integer::UNSIGNED);
return v; 
}




=
==23926==ERROR: AddressSanitizer: heap-use-after-free on address 
0x82607880 at pc 0xca7153cc bp 0xdc752330 sp 0xdc752350
READ of size 1 at 0x82607880 thread T0
#0 0xca7153c8 in 
send_broker_message(std::__cxx11::basic_string, std::allocator >, int, CryptoPP::RSAFunction, 
int, std::__cxx11::basic_string, 
std::allocator >, unsigned short, std::__cxx11::basic_string, std::allocator >, bool) 
../src/libs/lib_udp_messages.cpp:589
#1 0xca652f30 in main ../src/threading/server.cpp:128
#2 0x874c0990 in __libc_start_main (/lib/libc.so.6+0x24990)
#3 0xca654c74 in _start (/home/root/p2p_sockets/server+0xc4c74)

0x82607880 is located 0 bytes inside of 513-byte region 
[0x82607880,0x82607a81)
freed by thread T0 here:
#0 0x8798ebc8 in operator delete(void*, unsigned long) 
(/usr/lib/libasan.so.6+0xa8bc8)
#1 0xca715310 in __gnu_cxx::new_allocator::deallocate(char*, 
unsigned long) 
/opt/fsl-imx-xwayland/5.10-hardknott/sysroots/cortexa53-crypto-poky-linux/usr/include/c++/10.2.0/ext/new_allocator.h:133
#2 0xca715310 in std::allocator_traits 
>::deallocate(std::allocator&, char*, unsigned long) 
/opt/fsl-imx-xwayland/5.10-hardknott/sysroots/cortexa53-crypto-poky-linux/usr/include/c++/10.2.0/bits/alloc_traits.h:492
#3 0xca715310 in std::__cxx11::basic_string, std::allocator >::_M_destroy(unsigned long) 
/opt/fsl-imx-xwayland/5.10-hardknott/sysroots/cortexa53-crypto-poky-linux/usr/include/c++/10.2.0/bits/basic_string.h:237
#4 0xca715310 in std::__cxx11::basic_string, std::allocator >::_M_dispose() 
/opt/fsl-imx-xwayland/5.10-hardknott/sysroots/cortexa53-crypto-poky-linux/usr/include/c++/10.2.0/bits/basic_string.h:232
#5 0xca715310 in std::__cxx11::basic_string, std::allocator >::~basic_string() 
/opt/fsl-imx-xwayland/5.10-hardknott/sysroots/cortexa53-crypto-poky-linux/usr/include/c++/10.2.0/bits/basic_string.h:658
#6 0xca715310 in 
send_broker_message(std::__cxx11::basic_string, std::allocator >, int, CryptoPP::RSAFunction, 
int, std::__cxx11::basic_string, 
std::allocator >, unsigned short, std::__cxx11::basic_string, std::allocator >, bool) 
../src/libs/lib_udp_messages.cpp:532
#7 0xca652f30 in main ../src/threading/server.cpp:128
#8 0x874c0990 in __libc_start_main (/lib/libc.so.6+0x24990)
#9 0xca654c74 in _start (/home/root/p2p_sockets/server+0xc4c74)

previously allocated by thread T0 here:
#0 0x8798dc48 in operator new(unsigned long) 
(/usr/lib/libasan.so.6+0xa7c48)
#1 0xca6655f4 in void std::__cxx11::basic_string, std::allocator 
>::_M_construct<__gnu_cxx::__normal_iterator > > 
>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, 
std::forward_iterator_tag) 
/opt/fsl-imx-xwayland/5.10-hardknott/sysroots/cortexa53-crypto-poky-linux/usr/include/c++/10.2.0/bits/basic_string.tcc:219
#2 0xca6655f4 in void std::__cxx11::basic_string, std::allocator 
>::_M_construct_aux<__gnu_cxx::__normal_iterator > > 
>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, 
std::__false_type) 
/opt/fsl-imx-xwayland/5.10-hardknott/sysroots/cortexa53-crypto-poky-linux/usr/include/c++/10.2.0/bits/basic_string.h:247
#3 0xca6655f4 in void std::__cxx11::basic_string, std::allocator 
>::_M_construct<__gnu_cxx::__normal_iterator > > 
>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >) 
/opt/fsl-imx-xwayland/5.10-hardknott/sysroots/cortexa53-crypto-poky-linux/usr/include/c++/10.2.0/bits/basic_string.h:266
#4 0xca6655f4 in std::__cxx11::basic_string, std::allocator 
>::basic_string<__gnu_cxx::__normal_iterator > >, 
void>(__gnu_cxx::__normal_iterator > >, 
__gnu_cxx::__normal_iterator > >, std::allocator const&) 
/opt/fsl-imx-xwayland/5.10-hardknott/sysroots/cortexa53-crypto-poky-linux/usr/include/c++/10.2.0/bits/basic_string.h:628
#5 0xca6655f4 in 

Re: [cryptopp-users] Re: Strange behavior with -static compilation flag

[Jeffrey Walton]

On Tue, Apr 25, 2023 at 7:12 PM Dwight Kulkarni  wrote:
>
> I got it working by implementing the raw Integer method. See my code below, 
> previous encryption is commented out. I don't know why but it wasn't working 
> otherwise and I think it has something to do with memory allocation maybe it 
> works with -static flag because some references are staying in scope as the 
> entire library is loaded into RAM ?
>
> I had to implement the PKCS1v15 again but I would like to know what is wrong 
> so I can write the code accordingly.
>
> I have the Integer c.
>
> 1) If I use snippet 1, get the vector and then read it into a string "res" 
> and return it, this works.
>
> 2) If I use snippet 2, aka do the exact same thing in the function. It 
> doesn't work. I am trying to think whether the Vector needs to be declared 
> with new ? I am passing back the whole object not a pointer, so it should not 
> go out of scope ?? But maybe the resarr2 is not a deep copy and when it goes 
> out of scope the string data is also destroyed ?? On the other side, the 
> serve complains with Snippet 2 and not with Snippet 1.

If you want someone to look at your programs, you need to provide a
minimal reproducer somewhere it can be cloned like GitHub or GitLab.
I'm not going to try to copy/paste it from the mailing list. I'm also
not going to try to make it compile due to missing functions and
missing main().

Now, onto your memory problems. Use Address Sanitizer or Valgrind to
locate the memory error. I recommend Address Sanitizer (Asan). Asan
produces the best debug and diagnostics. Follow these steps.

# where the Crypto++ sources are
cd cryptopp
make distclean

# make the library
CXXFLAGS="-DNDEBUG -g3 -O1 -fsanitize=address" make -j 5

# test the library. Notice no memory errors
./cryptest.exe vv

# copy your test program. Be sure to name it *.cxx
cp ../../test.cxx .
g++ -o test.exe -DNDEBUG -g3 -O1 -I. -fsanitize=address test.cxx ./libcryptopp.a

# run your program
./test.exe

Attached is my broken test.cxx. I used a vector that was too small:

size_t len = n.MinEncodedSize(Integer::UNSIGNED);
std::vector v(len-4);
n.Encode((byte*)[0], v.size()+4, Integer::UNSIGNED);

Here is the result of my broken test program:

$ g++ -o test.exe -DNDEBUG -g3 -O1 -I. -fsanitize=address test.cxx
./libcryptopp.a
$ ./test.exe
=
==12167==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x6020003c at pc 0x7ffb24239e67 bp 0x7ffd10274f30 sp
0x7ffd102746d8
WRITE of size 1 at 0x6020003c thread T0
#0 0x7ffb24239e66 in __interceptor_memmove
../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:810
#1 0x55a0a1c8cac2 in memmove
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:36
#2 0x55a0a1c8cac2 in CryptoPP::ArraySink::Put2(unsigned char
const*, unsigned long, int, bool)
/home/jwalton/cryptopp/filters.cpp:545
#3 0x55a0a1b1f642 in
CryptoPP::BufferedTransformation::Put(unsigned char const*, unsigned
long, bool) /home/jwalton/cryptopp/cryptlib.h:1689
#4 0x55a0a1b1f642 in
CryptoPP::BufferedTransformation::Put(unsigned char, bool)
/home/jwalton/cryptopp/cryptlib.h:1679
#5 0x55a0a1b1f642 in
CryptoPP::Integer::Encode(CryptoPP::BufferedTransformation&, unsigned
long, CryptoPP::Integer::Signedness) const
/home/jwalton/cryptopp/integer.cpp:3439
#6 0x55a0a1b1fa84 in CryptoPP::Integer::Encode(unsigned char*,
unsigned long, CryptoPP::Integer::Signedness) const
/home/jwalton/cryptopp/integer.cpp:3431
#7 0x55a0a1af64ac in main /home/jwalton/cryptopp/test.cxx:18
#8 0x7ffb23a29d8f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#9 0x7ffb23a29e3f in __libc_start_main_impl ../csu/libc-start.c:392
#10 0x55a0a1af6004 in _start (/home/jwalton/cryptopp/test.exe+0x66004)

0x6020003c is located 0 bytes to the right of 12-byte region
[0x60200030,0x6020003c)
allocated by thread T0 here:
#0 0x7ffb242b61c7 in operator new(unsigned long)
../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x55a0a1af632c in __gnu_cxx::new_allocator::allocate(unsigned long, void const*)
/usr/include/c++/11/ext/new_allocator.h:127
#2 0x55a0a1af632c in std::allocator_traits >::allocate(std::allocator&, unsigned long)
/usr/include/c++/11/bits/alloc_traits.h:464
#3 0x55a0a1af632c in std::_Vector_base >::_M_allocate(unsigned long)
/usr/include/c++/11/bits/stl_vector.h:346
#4 0x55a0a1af632c in std::_Vector_base >::_M_create_storage(unsigned long)
/usr/include/c++/11/bits/stl_vector.h:361
#5 0x55a0a1af632c in std::_Vector_base >::_Vector_base(unsigned long,
std::allocator const&)
/usr/include/c++/11/bits/stl_vector.h:305
#6 0x55a0a1af632c in std::vector >::vector(unsigned long,
std::allocator const&)
/usr/include/c++/11/bits/stl_vector.h:511
#7 0x55a0a1af632c in main /home/jwalton/cryptopp/test.cxx:17

SUMMARY: AddressSanitizer: heap-buffer-overflow

[cryptopp-users] Re: Strange behavior with -static compilation flag

[Dwight Kulkarni]

I got it working by implementing the raw Integer method. See my code below, 
previous encryption is commented out. I don't know why but it wasn't 
working otherwise and *I think it has something to do with memory 
allocation maybe it works with -static flag because some references are 
staying in scope as the entire library is loaded into RAM ? *

I had to implement the PKCS1v15 again but I would like to know what is 
wrong so I can write the code accordingly.

I have the Integer c.  

1) If I use snippet 1, get the vector and then read it into a string "res" 
and return it, this works.

2) If I use snippet 2, aka do the exact same thing in the function. It 
doesn't work. I am trying to think whether the Vector needs to be declared 
with *new *? I am passing back the whole object not a pointer, so it should 
not go out of scope ?? But maybe the resarr2 is not a deep copy and when it 
goes out of scope the string data is also destroyed ?? On the other side, 
the serve complains with Snippet 2 and not with Snippet 1.


Snippet 1:  (works)
std::vector resarr2 = convert_cryptopp_integer(c);
string res(resarr2.begin(), resarr2.end());
return res;

Snippet  2: (doesn't work)
string res = convert_cryptopp_integer_str(c);
return res;

Functions:
std::vector convert_cryptopp_integer(Integer n){
const size_t len = n.MinEncodedSize(Integer::UNSIGNED);

std::vector v;
v.resize(len);
n.Encode((byte*)[0], v.size(), Integer::UNSIGNED);

//std::cout << "Iostream: " << std::hex << n << std::endl;
std::cout << "Iostream: " << n << std::endl;
std::cout << " Vector: ";
for(size_t i : v) { std::cout << (i & 0xff); }
std::cout << " Done vector: " << endl;
for(size_t i : v) { std::cout << int(i) << " "; }
std::cout << " Done cout: " << endl;
std::cout << std::endl;
return v; 
}

string convert_cryptopp_integer_str(Integer n){
std::vector resarr2 = convert_cryptopp_integer(n);
string res(resarr2.begin(), resarr2.end());
return res;
}



std::string encrypt_rsa(std::string message, CryptoPP::RSA::PublicKey key)
{

try{
/* This was the previous code I couldn't get working without the -static 
flag

cout << " In encrypt rsa string " << endl;
std::string str(message.begin(), message.end());
message = b64encode(str);
CryptoPP::AutoSeededRandomPool rng;

//CryptoPP::RSAES_OAEP_SHA_Encryptor encryptor(key);
CryptoPP::RSAES_PKCS1v15_Encryptor encryptor(key);
std::string ciphertext;
CryptoPP::StringSource(message, true, new CryptoPP::PK_EncryptorFilter(rng, 
encryptor, new CryptoPP::StringSink(ciphertext)));
return ciphertext;
*/

std::string str(message.begin(), message.end());
string message = b64encode(str);
cout << " Got message of length" << message.length() << endl;
//convert the message to b64
string ts="\0"s; 
ts += "\2"s;
//Add the 00 02 start header 
int target_length = key.GetModulus().ByteCount();
int msglength = message.length();
int padding_length = target_length - msglength - 3;

//calculate the padding length for PKCS1 v1.5
SecByteBlock rand(padding_length);
OS_GenerateRandomBlock(true, rand, padding_length);
string rands;
HexEncoder hex(new StringSink(rands));
hex.Put(rand, rand.size());
hex.MessageEnd();

std::regex reg("\0");
rands = std::regex_replace(rands,reg,"a");
rands.erase(padding_length);
//generate random padding, replace any NULLs with "a" 

if(message.size() resarr2 = convert_cryptopp_integer(c);
string res(resarr2.begin(), resarr2.end());
//This works 
//string res = convert_cryptopp_integer_str(c);
//This line above doesn't work is it memory issue of the vector going 
out of scope??

return res;

}
catch(Exception e)
{
std::cout << "error encrypting RSA " << e.what();
return "";
}
}



On Tuesday, April 25, 2023 at 4:47:38 PM UTC-4 Dwight Kulkarni wrote:

> Hi all:
>
> ldd ./server  compiled without the -static flag shows following .so 
> dependencies.
>
> Since the -static flag will add the same libraries as .a form, it will 
> compile a slightly different version. I am trying to think why the 
> encryption would produce two different results, maybe something like big 
> endian or little endian treatment in a particular function ? Maybe 
> difference in the random generator ? Maybe byte size differences due to 
> typedef ? 
>
> linux-vdso.so.1 (0x7ffc5e0d7000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
> (0x7f8712987000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f87125e9000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f87123d1000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
> (0x7f87121b2000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8711dc1000)
> /lib64/ld-linux-x86-64.so.2 (0x7f87131e2000)
>
> On Tuesday, April 25, 2023 at 2:47:34 PM UTC-4 Dwight Kulkarni wrote:
>
>> Further info:
>>
>> *without -static*, this is the output from the remote server:
>>
>> broker got data of size  512
>> Broker handler thread started... 512
>>  first two bytes are  128  and  198  and  154
>> *clear text begins with  68 180 

[cryptopp-users] Re: Strange behavior with -static compilation flag

[Dwight Kulkarni]

Hi all:

ldd ./server  compiled without the -static flag shows following .so 
dependencies.

Since the -static flag will add the same libraries as .a form, it will 
compile a slightly different version. I am trying to think why the 
encryption would produce two different results, maybe something like big 
endian or little endian treatment in a particular function ? Maybe 
difference in the random generator ? Maybe byte size differences due to 
typedef ? 

linux-vdso.so.1 (0x7ffc5e0d7000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f8712987000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f87125e9000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f87123d1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f87121b2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8711dc1000)
/lib64/ld-linux-x86-64.so.2 (0x7f87131e2000)

On Tuesday, April 25, 2023 at 2:47:34 PM UTC-4 Dwight Kulkarni wrote:

> Further info:
>
> *without -static*, this is the output from the remote server:
>
> broker got data of size  512
> Broker handler thread started... 512
>  first two bytes are  128  and  198  and  154
> *clear text begins with  68 180 -->> this should be 00 02*
> Either no 00 02 beginning block or no 00 separator byte found in proper 
> range
> Decryption failed
> Exception occurred:  'NoneType' object has no attribute 'decode'
>
>
> with -static flag, this is the output from the remote server:
>
> broker got data of size  512
> Broker handler thread started... 512
>  first two bytes are  51  and  252  and  242
> *clear text begins with  0 2  -> this is the correct value*
> Got base64 bytes 
>  
> b'eyJtZXNzYWdlIjoiMSIsInRybiI6MzM0NjQ1NjksInNlc3Npb24iOiJzc2Vzc2lvbiIsInBhc3Njb2RlIjoic3Bhc3Njb2RlIiwiZGF0ZXRpbWUiOiIwNC8yNS8yMDIzIDE4OjE1OjA0LjEwOCIsInNlcmlhbCI6InNzZXJpYWwiLCJjYW1lcmFfcG9ydCI6NTAwMCwia2V5IjoiTURObE1XWTBOMlUyTnpFNE1HTXdaak5pWkRZeE1UZ3haVGcyT0dFd05XST0iLCJpdiI6Ik9ETmtZMk0zTVdJek5UUmtaVFUyTUROak1HVTRaakptWlRNME5UQmhZMk09IiwidCI6Mn0='
> initializing the lock...
>
> On Tuesday, April 25, 2023 at 2:33:23 PM UTC-4 Dwight Kulkarni wrote:
>
>> Hi all,
>>
>> I have my RSA encrypt function as below.
>>
>> I compile my program with the following:
>>
>> g++ -g -c -static -pthread -I../ -I/data/prj/external-libs/include/cryptopp/ 
>> ../src/threading/server.cpp
>>
>> g++ -g ../lbin/*.o -static -pthread -o server -L/data/prj/external-libs/lib/ 
>> -l:libcryptopp.a
>>
>> Here is what is strange.
>>
>> If I include the -static flag, when I run the encrypt_rsa command below 
>> on the remote server it correctly decrypts.
>>
>> If I remove the -static flag, on the remove server it doesn't get the 
>> proper message. However, the message that locally encrypted and decrypted 
>> still works.
>>
>> It doesn't throw any error, encryption completes, but when the server 
>> receives it, it doesn't decrypt properly.
>>
>> During compilation of the .a library from makefile it did not have a 
>> -static flag.
>>
>>
>>
>>
>> std::string encrypt_rsa(std::string message, CryptoPP::RSA::PublicKey key
>> )
>> {
>>
>> try{
>> cout << " In encrypt rsa string " << endl;
>> message = b64encode(message);
>> CryptoPP::AutoSeededRandomPool rng;
>>
>> //CryptoPP::RSAES_OAEP_SHA_Encryptor encryptor(key);
>> CryptoPP::RSAES_PKCS1v15_Encryptor encryptor(key);
>> std::string ciphertext;
>> CryptoPP::StringSource(message, true, new CryptoPP::PK_EncryptorFilter(
>> rng, encryptor, new CryptoPP::StringSink(ciphertext)));
>> return ciphertext;
>>
>> }
>> catch(...)
>> {
>> std::cout << "error encrypting RSA";
>> return "";
>> }
>> }
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/64a04b0e-d8ed-4eb5-a1e2-901b49a9824cn%40googlegroups.com.

[cryptopp-users] Re: Strange behavior with -static compilation flag

[Dwight Kulkarni]

Further info:

*without -static*, this is the output from the remote server:

broker got data of size  512
Broker handler thread started... 512
 first two bytes are  128  and  198  and  154
*clear text begins with  68 180 -->> this should be 00 02*
Either no 00 02 beginning block or no 00 separator byte found in proper 
range
Decryption failed
Exception occurred:  'NoneType' object has no attribute 'decode'


with -static flag, this is the output from the remote server:

broker got data of size  512
Broker handler thread started... 512
 first two bytes are  51  and  252  and  242
*clear text begins with  0 2  -> this is the correct value*
Got base64 bytes 
 
b'eyJtZXNzYWdlIjoiMSIsInRybiI6MzM0NjQ1NjksInNlc3Npb24iOiJzc2Vzc2lvbiIsInBhc3Njb2RlIjoic3Bhc3Njb2RlIiwiZGF0ZXRpbWUiOiIwNC8yNS8yMDIzIDE4OjE1OjA0LjEwOCIsInNlcmlhbCI6InNzZXJpYWwiLCJjYW1lcmFfcG9ydCI6NTAwMCwia2V5IjoiTURObE1XWTBOMlUyTnpFNE1HTXdaak5pWkRZeE1UZ3haVGcyT0dFd05XST0iLCJpdiI6Ik9ETmtZMk0zTVdJek5UUmtaVFUyTUROak1HVTRaakptWlRNME5UQmhZMk09IiwidCI6Mn0='
initializing the lock...

On Tuesday, April 25, 2023 at 2:33:23 PM UTC-4 Dwight Kulkarni wrote:

> Hi all,
>
> I have my RSA encrypt function as below.
>
> I compile my program with the following:
>
> g++ -g -c -static -pthread -I../ -I/data/prj/external-libs/include/cryptopp/ 
> ../src/threading/server.cpp
>
> g++ -g ../lbin/*.o -static -pthread -o server -L/data/prj/external-libs/lib/ 
> -l:libcryptopp.a
>
> Here is what is strange.
>
> If I include the -static flag, when I run the encrypt_rsa command below on 
> the remote server it correctly decrypts.
>
> If I remove the -static flag, on the remove server it doesn't get the 
> proper message. However, the message that locally encrypted and decrypted 
> still works.
>
> It doesn't throw any error, encryption completes, but when the server 
> receives it, it doesn't decrypt properly.
>
> During compilation of the .a library from makefile it did not have a 
> -static flag.
>
>
>
>
> std::string encrypt_rsa(std::string message, CryptoPP::RSA::PublicKey key)
> {
>
> try{
> cout << " In encrypt rsa string " << endl;
> message = b64encode(message);
> CryptoPP::AutoSeededRandomPool rng;
>
> //CryptoPP::RSAES_OAEP_SHA_Encryptor encryptor(key);
> CryptoPP::RSAES_PKCS1v15_Encryptor encryptor(key);
> std::string ciphertext;
> CryptoPP::StringSource(message, true, new CryptoPP::PK_EncryptorFilter(rng, 
> encryptor, new CryptoPP::StringSink(ciphertext)));
> return ciphertext;
>
> }
> catch(...)
> {
> std::cout << "error encrypting RSA";
> return "";
> }
> }
>

-- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cryptopp-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cryptopp-users/c66e7ca1-bf74-4a38-8beb-cf30ee4172c9n%40googlegroups.com.