0
$\begingroup$

I know as programming languages C and java , and I know that java is slow so for this reason it is not suitable for cryptography applications espacially low level programming (manipulating bits) , so for this reason I turned to C as programming language but C is difficult in some how especially for GUI (graphical interfaces) , inaddition to this there is no byte type . My question is can we integrate C to java . it means when preparing GUI I use java and when programming the application I use C it is my first suggestion for asking you if it is possible and if we will not have a slow runtime. secondly using delphi ruther than C and java so , please advice me I am in adeadline ,and i must take a decision.

$\endgroup$

closed as primarily opinion-based by e-sushi, DrLecter, Seth, archie, poncho Dec 3 '14 at 3:12

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

3
$\begingroup$

You can call C from Java. You can call C libraries from just about anything.

Java isn't suitable for some cryptographic applications because you can't guard against garbage collector attacks, not because it's slow. It's not particularly slow. C does have a byte type, it's called "char". Object Pascal (Delphi) isn't a systems programming language, and so shouldn't be used to implement a crypto library.

Finally, do not implement your own cryptographic algorithms. Use an existing library.

$\endgroup$
  • $\begingroup$ Java also has a byte type, but you cannot specify that it isn't copied to another location or that it is allocated from a specific type of memory (that e.g. isn't copied onto the disk, forgot name of file / partition :) ). $\endgroup$ – Maarten Bodewes Dec 1 '14 at 12:12
  • $\begingroup$ Yes, the difficulty of having memory managed for you leads to the various types of garbage collector attacks. Note that something like C doesn't guarantee safety, it simply makes safety potentially possible. You still need to carefully examine the output of the compiler to ensure things like buffer zeroing actually happens. There are languages (Rust comes to mind, as does Cryptol for hardware) that specifically try to make this easier. $\endgroup$ – SAI Peregrinus Dec 6 '14 at 19:08
  • $\begingroup$ That would have been the swap file or partition. $\endgroup$ – Maarten Bodewes Dec 7 '14 at 1:44
2
$\begingroup$

Java isn't as fast as C for cryptographic operations, it is a factor of 2 to 10 times slower, depending on the algorithm - according to my 15 year experience. With the current processors that's often a smaller issue than you may think, you can still get very respectable speeds with Java (much higher than with non-native scripting code for instance). That said, most will argue that Java is more cross platform, easier to maintain and more secure than C.

I would seriously propose you develop your application in Java (or for instance C#). Then if your crypto really requires optimization you have plenty of options:

  • upgrade your JCE provider (Java crypto is pluggable) to a provider that uses native code
  • use JNI (or higher level interface based on JNI) to call native code from Java
  • upgrade to a newer Java (the latest Java 7 & 8 can perform AES-NI instructions for certain modes of encryption)
  • upgrade the hardware

As with any programming language, most of the time when users complain that an application does not fast enough, it is because they use the wrong API, or use the correct API incorrectly.

As SAI Peregrinus correctly says there may be some issues with Java if you want to purge keys and sensitive information from memory. If you need that kind of protection you may want to look at libraries such as NaCl. You could also deploy a HSM (from Java) if you get really serious - about 7 to 8000 dollars worth of seriousness - about crypto.

$\endgroup$
  • $\begingroup$ Note that Java 8 seems to extend the key and cipher interfaces to allow purging of sensitive information, but I'm not sure that already takes place. $\endgroup$ – Maarten Bodewes Dec 1 '14 at 12:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.