My only comment would be that given a "complete" "mobile" configuration
(Android AND iOS) that there be some generic mobile target that would
package the lib* files appropriately to avoid them all overwriting
libcryptopp.a. And for that matter, the .o and exes should probably managed
as well,
I'm trying to use crypto++ on android. I seem to have it compiled and
linking, my app starts.
When I call my first encryption function it crashes:
F/libc (24620): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xdeadcab1 in
tid 24645 (QtThread)
The simple encryption function is :
I'm actually using cryptopp on android and ios, and they have dfferent
crash behaviors. The android issue is in another thread, and seems related
to stl.
In iOS I get farther in my app, but when it comes time to do a FileSource
to FileSync encryption it locks the device. Has anyone seen
On Wednesday, December 16, 2015 at 4:33:16 PM UTC-5, Jeffrey Walton wrote:
>
>
>
> On Wednesday, December 16, 2015 at 2:54:53 PM UTC-5, jh...@emocha.com
> wrote:
>>
>> I'm trying to use crypto++ on android. I seem to have it compiled and
>> linking, my app starts.
>>
>> When I call my first
On Thursday, December 17, 2015 at 3:13:51 AM UTC-5, John Lester Romano
wrote:
>
> Got the answer. I just need to INCLUDEPATH to where are the sources are
> (INCLUDEPATH += /home/ron/Downloads/cryptopp). Thanks
>
> On Thursday, December 17, 2015 at 3:29:38 PM UTC+8, John Lester Romano
> wrote:
I have two sets of issues. One seems to be linker related:
E/art ( 8857): dlopen("/data/app/com.app/lib/arm/libcryptopp-and.so",
RTLD_LAZY) failed: dlopen failed: library "libstlport_shared.so" not found
So I add:
ANDROID_EXTRA_LIBS +=
/Users/jhihn/Downloads/android-ndk-
y "libstlport_shared.so" not
> found
> >
> > So I add:
> >
> > ANDROID_EXTRA_LIBS +=
> /Users/jhihn/Downloads/android-ndk-r10e/sources/cxx-stl/
> > stlport/libs/armeabi-v7a/libstlport_shared.so
> >
>
> This is always a point of frustr
I'll probably have some time allotted towards the end of this week, I'll
give it a look-see.
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about
I was just talking to some Qt people about the stlport issues I'm having
they told me I need to link against gnu-shared. Which is completely doable
in Crypto++ for android. But I mentioned the GPL issue and they seemed to
not think it was an issue, so I goodled. I found:
While I agree nuanced legal debates are not technically productive, not
applicable to everyone at the same time, the stlport issue did cause some
technical headaches.
I agree that the right action is to take a survey and see who is bothering
to use stlport vs gnustl.
With that said, I request
So I think I'm getting somewhere... and sorry to be a bother.
Qt uses gnu-shared stl.
1. Can we get the setenv-{platform} scripts into the regular source?
2. When I build using the new scripts and source, I can't do my old trick
of renaming the library:
dlopen failed: library
I did hack the makefile to remove HAS_SOLIB_VERSION. But I still get the
error.
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and
"one *FREE* account"
We could get a paid account. Also, I think bitbucket git accounts are
cheaper than github. But at this point we would need donations... Perhaps
we could have the service provider donate to the project for the exposure.
--
--
You received this message because you are
Well I had force that to zero in the makefile itself, it seems to stay.
The files generated are now properly named without the version suffix, but
it still seems to internally want libcryptopp.so.5.6
I think SOLIB_FLAGS needs an ifdef for HAS_SOLIB_VERSION ?
--
--
You received this message
I think this would be an awesome help! Especially for those of us doing
multi-platform development not privy to each platform's flags.
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to
On Monday, December 21, 2015 at 5:37:53 PM UTC-5, jh...@emocha.com wrote:
>
>
>>>
>> Hmmm... I cannot duplicate it. I just tried again on iOS 6.0 and 8.1.
>>
>> For iOS, I test using two jail broken devices: (1) iPad2 running 8.1 and
>> (2) iPad3 running iOS 6.0. I cross compile it according to
On Monday, December 21, 2015 at 6:01:24 PM UTC-5, jh...@emocha.com wrote:
>
>
>
> On Monday, December 21, 2015 at 5:37:53 PM UTC-5, jh...@emocha.com wrote:
>>
>>
>>> Hmmm... I cannot duplicate it. I just tried again on iOS 6.0 and 8.1.
>>>
>>> For iOS, I test using two jail broken devices:
>
>
>>
> Hmmm... I cannot duplicate it. I just tried again on iOS 6.0 and 8.1.
>
> For iOS, I test using two jail broken devices: (1) iPad2 running 8.1 and
> (2) iPad3 running iOS 6.0. I cross compile it according to
> https://www.cryptopp.com/wiki/IOS_%28Command_Line%29 . I SCP
>
The code below is crashing in MeterFilter::PutMaybeModifiable
Stack trace
1 CryptoPP::StreamTransformationFilter::FirstPut(unsigned const char *)
filters.cpp 632 0x10008ca83
2 CryptoPP::FilterWithBufferedInput::PutMaybeModifiable(unsigned char *,
unsigned long, int, bool, bool) filters.cpp
Thanks Jeff, but the more I dig into this the more lost I am, and I'm
getting frustrated. I've done similar attachment-style cascading IO before.
My issues are:
1. [As discussed before] For some reason FileSource with the pump
argument=true attempts to allocate the entire size of the file? This
I've refactored my code several times.
You say " You should probably call MessageEnd() on the
StreamTransformationFilter."
I'm not sure how I get to the STF now, as my code now looks like:
CryptoPP::CFB_Mode::Encryption *e = new
CryptoPP::CFB_Mode::Encryption((const byte
On Wednesday, December 16, 2015 at 7:37:22 PM UTC-5, Jeffrey Walton wrote:
>
>
> What I do is concentrate my error checking and analysis on the desktop
>> OSes, like OS X and Linux. Once I am satisfied the "core" logic is sound, I
>> port it to another platform, like iOS and Android. The
Looks like it is down again
A database query error has occurred. This may indicate a bug in the
software.
- Query:
SELECT
On Tuesday, December 22, 2015 at 4:24:31 AM UTC-5, Jeffrey Walton wrote:
>
>
>>
> This might be a little closer to what you are doing:
>
> MeterFilter* meter;
> StreamTransformationFilter* stf;
>
> FileSource fs("/dev/zero", false, stf = new
> StreamTransformationFilter(enc, meter =
Crypto++ for me is only doing a few things, no parameterized algorithms. I
use some sources, some sinks, and the CFB AES-256 encryption (no
decryption). Is there a way I can start from clean and compile-in only the
subset of classes I need? The library weighs in at 172 megs at last check
for
I send AES256 on ARM (linux, bsd) to x86-64 (linux) and decrypt. I'm
crossing an endian boundary and OSs. I can only conclude it is your code,
or a compiler flag. Probably on the windows side, as that is the only
platform I don't touch.
--
--
You received this message because you are
On Thursday, January 14, 2016 at 1:54:07 PM UTC-5, Jeffrey Walton wrote:
>
>
>
>> My Apple platforms are:
>>
>>- AppleTVOS.platform
>>- AppleTVSimulator.platform
>>- MacOSX.platform
>>- WatchOS.platform
>>- WatchSimulator.platform
>>- iPhoneOS.platform
>>-
I'm thinking Apple changed something in their linker, because this is
happening for iOS OSX and Android, and it's all the same class.
A simple re-compile fixes it.
I've got no other idea.
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To
I might be, but I've never done this before, so I don't know what it
entails.
If it's only as a fall back then I should be available.
What should we have the student work on?
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe,
Of course not, you never converted it back from base64.
>
>
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is
It's down again.
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
---
You
I have been doing regular builds of my software that uses crypto++ for a
while now. Today I did a build, then accidentally pulled to the latest head
of crypto, and now my software doesn't compile.
It says:
Undefined symbols for architecture armv7:
"vtable for CryptoPP::Base64Decoder",
!/bin/bash
objs=
rm libcryptopp-ios.a
#device
function build() {
for arch in $2
do
. ./setenv-ios.sh $1 ${arch} > /dev/null
make distclean
file=libcrypto-ios-$arch.a
if [ -e $file ]; then
rm $file
fi
make -j 8 -f GNUmakefile-cross && mv libcryptopp.a $file
I just spent a while finding a bug because feedbackSize was not specified
in my code. The
CryptoPP::CFB_Mode::Encryption aes(_bKey, sizeof(_bKey), _iv);
should have been:
CryptoPP::CFB_Mode::Encryption aes(_bKey, sizeof(_bKey), _iv, 1);
I'm wondering why the CFB_Mode Encryption and
Could you explain?
I just spent days tracking down a bug because one implementation
(CryptoC++) used the default, and another implementation (Python) used 1 as
the default size. Given that a feature of CFB (as I understand it) is
pad-free, I do not understand why the python side would produce
35 matches
Mail list logo
