headers
yazwas | 1 Feb 2007 13:47
Picon

PGP Sign Message


Hello,

I'm new to crypto++, and I'm writting a program that creates an email
and then signs it with PGP,

I'm wondering how to do this in crypto++, if anyone could provide me
with a source sample of how this can be done, it would be huge help

Thankx in advance,

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe <at> googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
craftsman | 1 Feb 2007 10:00
Picon

problem linking cryptest.exe with MinGW gcc 3.4.2


Hello everyone!

I make'd the crypto++ with MinGW's gcc 3.2.3 and everything worked
fine.

Then I tied to compile it with gcc 3.4.2, which compiled everything
and linked the libcryptopp.a with no errors,
but when it started to link cryptest.exe, I got the following errors:

g++ -o cryptest.exe -g -pipe bench.o bench2.o test.o validat1.o
validat2.o validat3.o adhoc.o datatest.o regtest.o fipsalgt.o
dlltest.o -L. -lcryptopp  -lws2_32

/mingw/lib/libstdc++.a(eh_personality.o): multiple definition of
`typeinfo for std::exception'
bench.o:C:/Qt/cryptopp521_for_422/lubyrack.h:(.rdata
$_ZTISt9exception[typeinfo for std::exception]+0x0): first defined
here
/mingw/lib/libstdc++.a(eh_personality.o): multiple definition of
`typeinfo namefor std::exception'
bench.o:C:/Qt/cryptopp521_for_422/lubyrack.h:(.rdata
$_ZTSSt9exception[typeinfo name for std::exception]+0x0): first
defined here
/mingw/lib/libstdc++.a(new_opv.o): multiple definition of `typeinfo
for std::bad_alloc'
./libcryptopp.a(misc.o):C:/Qt/cryptopp521_for_422/misc.cpp:(.rdata
$_ZTISt9bad_alloc[typeinfo for std::bad_alloc]+0x0): first defined
here
/mingw/lib/libstdc++.a(new_opv.o): multiple definition of `typeinfo
(Continue reading)

Permalink | Reply | 501 comments |
headers
Wei Dai | 1 Feb 2007 16:04

Re: problem linking cryptest.exe with MinGW gcc 3.4.2


>From a Google search, it seems this error could be caused by multiple
installations of MinGW. Try doing a clean installation of MinGW on
another system and see if that fixes the problem. If not, and no one
else here can help, I suggest that you post the question to a MinGW
support group, since it seems to have more to do with MinGW than with
Crypto++.

On Feb 1, 5:00 pm, "craftsman" <porni... <at> gmail.com> wrote:
> Hello everyone!
>
> I make'd the crypto++ with MinGW's gcc 3.2.3 and everything worked
> fine.
>
> Then I tied to compile it with gcc 3.4.2, which compiled everything
> and linked the libcryptopp.a with no errors,
> but when it started to link cryptest.exe, I got the following errors:
>
> g++ -o cryptest.exe -g -pipe bench.o bench2.o test.o validat1.o
> validat2.o validat3.o adhoc.o datatest.o regtest.o fipsalgt.o
> dlltest.o -L. -lcryptopp  -lws2_32
>
> /mingw/lib/libstdc++.a(eh_personality.o): multiple definition of
> `typeinfo for std::exception'
> bench.o:C:/Qt/cryptopp521_for_422/lubyrack.h:(.rdata
> $_ZTISt9exception[typeinfo for std::exception]+0x0): first defined
> here
> /mingw/lib/libstdc++.a(eh_personality.o): multiple definition of
> `typeinfo namefor std::exception'
> bench.o:C:/Qt/cryptopp521_for_422/lubyrack.h:(.rdata
(Continue reading)

Permalink | Reply | 501 comments |
headers
RnySmile | 1 Feb 2007 17:12
Picon

AutoSeededRandomPool thread bug and WORKAROUND_MS_BUG_Q258000


Hi,

I found AutoSeededRandomPool have thread problems. e.g. when 10 thread
are running the function below, it throw exceptions.

void thread(void)
{
    CryptoPP::AutoSeededRandomPool rng;
}

By reading this post:

http://groups.google.com/group/cryptopp-users/browse_thread/thread/f3001108e50435ed/892a114268233265?lnk=gst&q=AutoSeededRandomPool&rnum=1#892a114268233265

I removing the #define WORKAROUND_MS_BUG_Q258000 in the config.h and
run the test again, it runs without any problem.

So I suggest remove the deine in the official version.

RnySmile

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe <at> googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 1 comment |
headers
Andrew Leung | 1 Feb 2007 19:45
Favicon

SecByteBlock conversion


Hi,

I was wondering how to grab the raw data out of a SecByteBlock. I am 
passing a signature over the network and would prefer it be a string or 
char* or byte*. Can I just use a HexEncoder on it with or without any 
changes? Thanks.

Andrew

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe <at> googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 1 comment |
headers
Busy++ | 3 Feb 2007 04:40
Picon

Re: SecByteBlock conversion


SecByteBlock`s usage is like Byte array.

i hope the Code will tell u anwser

SecByteBlock s(5);
...some process code ..
BYTE b[5];
b[i] = s[i];

On Feb 2, 2:45 am, Andrew Leung <ale... <at> soe.ucsc.edu> wrote:
> Hi,
>
> I was wondering how to grab the raw data out of a SecByteBlock. I am
> passing a signature over the network and would prefer it be a string or
> char* or byte*. Can I just use a HexEncoder on it with or without any
> changes? Thanks.
>
> Andrew

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe <at> googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Wei Dai | 3 Feb 2007 14:29

Re: AutoSeededRandomPool thread bug and WORKAROUND_MS_BUG_Q258000


Thanks for reminding me about this. I don't want to just remove this 
workaround since there may be old systems out there still affected by this 
bug. However I have checked in a fix to this threading bug, which I've also 
copied here:

diff -r1.6 osrng.cpp
88c88
<   static MicrosoftCryptoProvider m_Provider;
---
>   const MicrosoftCryptoProvider &m_Provider = 
> Singleton<MicrosoftCryptoProvider>().Ref();

----- Original Message ----- 
From: "RnySmile" <rnysmile <at> gmail.com>
To: "Crypto++ Users" <cryptopp-users <at> googlegroups.com>
Sent: Friday, February 02, 2007 12:12 AM
Subject: AutoSeededRandomPool thread bug and WORKAROUND_MS_BUG_Q258000

>
> Hi,
>
> I found AutoSeededRandomPool have thread problems. e.g. when 10 thread
> are running the function below, it throw exceptions.
>
> void thread(void)
> {
>    CryptoPP::AutoSeededRandomPool rng;
> }
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tomáš Vondra | 4 Feb 2007 09:14
Picon

Another SIGILL


This time it's the ASM block in integer.cpp containing the 'cpuid'
instruction, which checks for P4. It fails miserably on a below-Pentium
(probably) processor. Both in 5.2 and 5.4. Removal necessary - suggest you
ask the user about his computer in the makefile.
You really should tune the code checking for available optimisations.But now
it seems to be all to me. cryptest runs without errors.
Wondra

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe <at> googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 1 comment |
headers
Jeffrey Walton | 4 Feb 2007 17:00
Picon

Re: Another SIGILL


CPUID is only available only 486 (at certain stepping levels) and above.

On 2/4/07, TomᚠVondra <wondra <at> volny.cz> wrote:
>
> This time it's the ASM block in integer.cpp containing the 'cpuid'
> instruction, which checks for P4. It fails miserably on a below-Pentium
> (probably) processor. Both in 5.2 and 5.4. Removal necessary - suggest you
> ask the user about his computer in the makefile.
> You really should tune the code checking for available optimisations.But now
> it seems to be all to me. cryptest runs without errors.
> Wondra

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe <at> googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
kan | 5 Feb 2007 15:23
Picon
Gravatar

Base 32 alphabet


The Base 32 encoding has two different alphabet types:
ABCDEFGHIJKMNPQRSTUVWXYZ23456789
and
ABCDEFGHIJKLMNOPQRSTUVWXYZ234567
You can see it here http://en.wikipedia.org/wiki/Base_32
Some systems expect second type, e.g. hmrc.gov.uk
The Crypto++ implements only first type, is it possible to include the
second in the library?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe <at> googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 3 comments |

Gmane