cross language encryption library for c++ and java
Aditya Pandit
web UI.
Is there any encryption library which has versions for java and c++
such that the same encrypted text can be read through a java program as
well as a c++ program.
Thanks,
Adi
Bryan Olson
> Is there any encryption library which has versions for java and c++
> such that the same encrypted text can be read through a java program as
> well as a c++ program.
Not sure I grasp the coss-language library concept, but the stated
goal is no problem. Decent crypto libraries implement standard
methods, so ciphertext is portable.
--
--Bryan
Joseph Ashwood
news:1127323962.5...@g44g2000cwa.googlegroups.com...
I'm not immediately aware of such a library, but any library that supports
one of the many standarda (OpenPGP, PKCS, etc) should be able to communicate
with any other such library. So for example in Java you'd want to use the
JCE, and in C++ Crypto++ should work quite well. They both share AES as a
primitive, both support ElGamal and RSA for key exchange (albeit rather
trickily for ElGamal), both support RSA and DSA signatures of the same type
for authentication. Then just add a bit of your own formatting to accomplish
what you need. In my experience the transition between the two is usually
more complicated by whether Java is working in ASCII, UTF, or another text
mode than by the cryptography.
Joe
Will Dickson
> GPGLib from GnuPG.
> Anyway, why not using JNI?
Overhead is frequently non-trivial. Plus you'd have to write / generate
then test / debug a fair amount of glue.
Will
John E. Hadstate
"Joseph Ashwood" <ash...@msn.com> wrote in message
news:_WkYe.849$G64...@newssvr12.news.prodigy.com...
> In my experience the transition between the two is usually
> more complicated by whether Java is working in ASCII, UTF,
> or another text mode than by the cryptography.
Indeed. The JCE works on bytes and byte arrays. This means
you either have to forgo the encryption of Unicode (strings
and char arrays), or you have to devise a way of converting
between Unicode and bytes. Either way, from the Java point
of view, it's not very programmer-friendly.
tomst...@gmail.com
Ahem... ASN.1?
JCE is probably defined for byte arrays because the ciphers are defined
for byte arrays. All the window dressing the world won't stop some
eventual post like yours with a "s/UTF/$MAGICCODE/" ...
So why write bloatware?
That said ... cheapshot ... Java sucks anyways. People write in it
because they just don't know better and are sucked into SunThought
(tm).
I had this run-in with some folk at SanDisk and they asked "why do you
think Java is not useful".
I then said, "know what a PC is? A DSL router? Playstation 2?
Bluetooth adapter? UNIX box last updated in 1994? etc... yeah my
single code base compiles and works on all of those."
Point is Java aside from being OOP [and I even question the "benefit"
of that] has no advantage over C. My source code base compiles without
modification on essentially ANYTHING you can think of [or so people
tell me].
/rant :-)
Tom
Joseph Ashwood
news:1127359750.2...@g44g2000cwa.googlegroups.com...
> That said ... cheapshot ... Java sucks anyways. People write in it
> because they just don't know better and are sucked into SunThought
> (tm).
I will disagree with you there. Yes, straight C can be highly effective, and
extremely efficient, and for crypto code is irreplacable except by asm, but
Java has some very interesting points. For example in my recent work Java
has been indispensible because of the ability to compile only once, but also
because of the exception handling, something very difficult to write in
straight C. Of course the product could be written in nearly pure C (needs a
GUI, which wouldn't be portable), but Java reduced the time scale for
implementation from man*years to man*months, and that is a very valuable
jump.
Joe
tomst...@gmail.com
Saying GUI code is only portable in Java is a bit loaded... things like
GTK+ have been ported to just about everywhere even including Win32
GDI.
As for exception handling that's coo and all no real gripes there,
except it isn't like you can't do error checking in C.
Secure development isn't supposed to be "trivial". Sure I wouldn't
code in asm if I wanted security because it's too low level but C
provides more than enough constructs to make legible code that is both
functional and expressive.
I mean I say
if (func() == error) { handle_error(); }
And you know what it means...
you say
try {
func();
}
catch (Exception e) {
handle_error(e);
}
... and ... um ... we mean the same thing... If you're really that lazy
you can do something like
[assumption OK == 0]
if (
(err = func1()) ||
(err = func2()) ||
...
) {
handle_error(err);
}
Which nets you something like
try {
func1();
func2();
...
}
catch (Exception e) {
handle_error(e);
}
So it isn't like you can't clump error checking/handling. And in my
[albeit contrived] examples both the C and Java are readable,
functional and the C is still 1 line shorter ;-)
Tom
Dave Howe
stick to industry-accepted algos and methods, it doesn't matter what library you
use, you can find a suitable library or package for the target system or language.
Personally, I use Bouncy Castle in java, as it supports a wide range of accepted
protocols, including s/mime (for which the canonical library in c++ would be
openssl) and openpgp (for which the canonical library for c++ is gpglib or the
pgpsdk on certain platforms, if you are willing to pay their fees)
David Taylor
>
> if (
> (err = func1()) ||
> (err = func2()) ||
> ...
> ) {
> handle_error(err);
> }
>
> Which nets you something like
>
> try {
> func1();
> func2();
> ...
> }
> catch (Exception e) {
> handle_error(e);
> }
>
> So it isn't like you can't clump error checking/handling. And in my
> [albeit contrived] examples both the C and Java are readable,
> functional and the C is still 1 line shorter ;-)
No, the C is hideous.
--
David Taylor
tomst...@gmail.com
> > So it isn't like you can't clump error checking/handling. And in my
> > [albeit contrived] examples both the C and Java are readable,
> > functional and the C is still 1 line shorter ;-)
>
> No, the C is hideous.
Um, ... ok.
Well ... um ... not much to say here... You apparently have an opinion
you can't back up with an argument.
Guess that's another victory for us C developers ;-)
Tom
David Taylor
No, C is good. C can do what you described fine.
However, your code:
if ((err = funcA(blah)) ||
(err = funcB(blah)) ||
(err = funcC(blah)) ||
...
)
{
handleError(err);
}
Is, at least IMO, not "readable" but hideous.
--
David Taylor
tomst...@gmail.com
> No, C is good. C can do what you described fine.
>
> However, your code:
>
> if ((err = funcA(blah)) ||
> (err = funcB(blah)) ||
> (err = funcC(blah)) ||
> ...
> )
> {
> handleError(err);
> }
>
> Is, at least IMO, not "readable" but hideous.
I don't see what is so unreadable about it. Perhaps you're differing
for the sake of differing?
There has been a LONG standing standard of "0 == OK" which pre-dates my
existence to say the least... So you can easily read it as expected.
E.g. execute all the functions unless one of them dies.
Granted in my own code I don't typically do this, I'll do one function
per if statement with the occasional goto to make cleanup simpler in
the event of an error.
Tom
David Taylor
> David Taylor wrote:
>> No, C is good. C can do what you described fine.
>>
>> However, your code:
>>
>> if ((err = funcA(blah)) ||
>> (err = funcB(blah)) ||
>> (err = funcC(blah)) ||
>> ...
>> )
>> {
>> handleError(err);
>> }
>>
>> Is, at least IMO, not "readable" but hideous.
>
> I don't see what is so unreadable about it. Perhaps you're differing
> for the sake of differing?
OK. I'll just say that I think there are significantly better
ways of writing that.
--
David Taylor
tomst...@gmail.com
> > I don't see what is so unreadable about it. Perhaps you're differing
> > for the sake of differing?
>
> OK. I'll just say that I think there are significantly better
> ways of writing that.
Yeah I agreed with that already. I said you *could* do it that way and
that it certainly isn't hard to read.
I'm sorry if your grasp of C and/or it's syntax is below par but for
the rest of us why should we be held to your level of comprehension?
The point of my post was to show that you can get decently easy to work
with error control in C without significantly polluting the code.
Specially after a while. I mean when I read LTC or LTM code I don't
really read the "if blah != CRYPT_OK" unless I'm looking for it. My
mind just sees the function call and it's arguments at this point.
I guess that's the difference that experience makes.
Tom
David Taylor
>
> I'm sorry if your grasp of C and/or it's syntax is below par but for
> the rest of us why should we be held to your level of comprehension?
What the hell are you talking about now?
Why do you find it necessary to insult everyone who disagrees
with you?
> The point of my post was to show that you can get decently easy to work
> with error control in C without significantly polluting the code.
The point of my post is that that _is_ poulluting the code.
In the exact situation you gave, with three single argument functions
then sure, it's absolutely fine.
The problem is most code doesn't consist of sequences of a couple
of single argument functions, and so it ends up rather more
convoluted than your example.
> Specially after a while. I mean when I read LTC or LTM code I don't
> really read the "if blah != CRYPT_OK" unless I'm looking for it. My
> mind just sees the function call and it's arguments at this point.
>
> I guess that's the difference that experience makes.
Oh STFU you smarmy git. I am entirely capable of reading (and writing)
C code. The point of writing readable code is (at least) two-fold:
1. So that people that aren't self-professed geniuses like yourself
are able to understand the code in the joyous days once you
leave.
2. So what you see "without looking" is what the code actually
does, not just what you think the code does because that's how you'd
have formatted it.
--
David Taylor
Zeljko Vrba
Hash: RIPEMD160
On 2005-09-22, David Taylor <david...@yadt.co.uk> wrote:
>
> The point of my post is that that _is_ poulluting the code.
> In the exact situation you gave, with three single argument functions
> then sure, it's absolutely fine.
>
I have coded both in Java, C and C++ and in my experience, try/catch blocks
and throw declarations on Java functions pollute code much more than simple
if()s in C.
Exceptions in Java are like a virus - either catch it (i.e. add another
try{}catch{} which is much more verbose than simple if) or declare it
propagating out of the function (i.e. again verbosity, and new decision
where to catch it).
Java designers did what every C++ book and style guide recommends NOT to do:
it uses exceptions to signal expected errors (an example: trying to convert an
invalid string like "123-b" to integer), instead of signalling _really_
unexpected conditions (e.g. out of memory, arithmetic overflow, and other,
generally environmental stuff, that the programmer has no control over).
Writing (hypothetical code; I've happily forgotten most of my Java coding
experience)
if(null == (x = Integer.parse(some_string))) {
// handle error
}
// do something
would be, at least to me, much clearer than
try {
x = Integer.parse(some_string);
// do something
} catch(SomethingIForgot) {
// handle error
}
because the former is:
a) less verbose
b) I immediately see where and how is the error handled and is it handled at
all. When I go hunting for bugs I first check my error handling code and
it helps having it near the action that caused the error than somewhere..
somewhere.. maybe not even in the same function!
Tom's example is not in any way less readable than the try/catch. And if you
want non-local exits in C (which you have with Java exceptions), you can
always reach for setjmp/longjmp. There are plenty small libraries that
package them up in a set of TRY/CATCH macros to make them more accesible.
Not to mention that writing exception-safe code is extremely hard. [i.e.
guaranteeing that you leave your object in a consistent state when an
exception is thrown part-way through some mutable method..]
Hm... thinking over that.. it would be very useful to promote exceptions into
a 'transaction' mechanism something like
x=2;
begin {
x = 3;
throw whatever;
}
so, before exiting to outer-level scope, x will be reset to 2. transaction is
commited if the begin ends just by 'falling over' the scope without any
intervening exception.
IMHO, without such a mechanism, naive use of exceptions can just produce
more buggy code..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQFDMwzCFtofFpCIfhMRA1OEAJ0T1acfHYxJwpwsVXzA+BGfJAftQgCfa+4H
54OsKT85ouY0eFe2FCQtOEk=
=TnBO
-----END PGP SIGNATURE-----
Peter Gutmann
cryptlib has bindings for C/C++ and Java (and Tcl, and Python, and Delphi, and
Visual Basic, and C#, and ...). BSAFE is also available in C and Java
versions.
Peter.
cleft
wrote:
You weren't kidding about the bindings for Visual Basic for cryptlib!
I hadn't been to the cryptlib site for a while, since the last time I
checked, the support for VB was fairly thin.
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/index.html
Now there is this site with VB support for cryptlib:
http://cryptlib.sogot.de/vb.html
The complete translation of cryptlib.h into criptlib.bas looks strong
and impressive..
Thank you.