Frequently Asked Questions
API index
Documentation
Java Cryptography Extension Specification
Utility scripts
Copyright and License
Development
Team
|
|
README or
Readme Src or
Readme Bin Frequently Asked Questions API index Documentation Java Cryptography Extension Specification Utility scripts Copyright and License |
Description and Information | Installation | "Regulations" and Patents | Implementation Choices | Compatibility Issues | Working with the Team | Strength, Reliability, Etc. | Performance | Known Bugs | Copyright and License | |
Cryptix Development Team |
$Revision: 1.45 $
$Date: 1999/07/31 20:35:56 $
The latest revision of this FAQ is available on a mirrored server near you. It will also be available in the next download.
Return to the Cryptix README. Headings below return to the above table of contents.
The Cryptix libraries contain a suite of cryptographic classes. There is an implementation for each of Java and Perl; this FAQ mainly concentrates on the Java version.
Some of the classes have optional native code for performance reasons. This code has been tested on Windows 95 and Windows NT (Intel x86). Previous versions have been tested on Solaris (SPARC), Linux (Intel x86) and IRIX (MIPS). Both source and binaries are available for various platforms (also see the section, "Use of Native Code.")
To download source or binaries, start at the Cryptix Mirror Index. We are actively looking for more mirror sites.
The mailing lists are explained on the Cryptix homepage. Click on the 'support' button.
Cryptix is provided for free, with no royalties. It is never likely to be anything else, and we (the owners) promise never to chase you for fees or royalties or whatever for any copy of Cryptix that has been released on this basis. All code was either provided on this basis, or written explicitly by the Cryptix Development Team.
Cryptix was originally written by Systemics, Ltd. The original developers believed that selling crypto code was not (and is not) a workable business. However, good strong crypto libraries were still required and were not then available.
The solution was to publish Cryptix as a freeware (or Open Source) library and encourage others to contribute, use and test the code. Then Cryptix was transferred over to the Internet community, in the guise of the Cryptix Development Team. This process is now complete, as releases from Cryptix-Java 2.2 and onwards have been substantially produced by people who have no direct relationship with Systemics.
In the meantime, Systemics specialises in financial cryptography applications.
There is no formal support for freeware users of Cryptix.
It is a freely released product, and the Cryptix Development Team has no budget for providing help or for fixing problems. We will try our best, but money-making projects come first. Often it will take us several years to get a chance to look at a question, so please be patient. Sometimes we don't ever solve problems.
Problems, bug reports and other requests should be posted to the mailgroups. We would encourage everyone to end their posts with "Has anyone else seen this?" or somesuch, and hope that someone has :))
The USENET newsgroup comp.lang.java.security is also a useful resource for questions about security in Java.
If anyone would like to discuss a more formal support arrangement, please mail us.
If private mail is necessary, send to any mail address listed in the feedback page on the Cryptix home page, and it will be redirected to the most appropriate place.
No, Cryptix is available from servers located around the world.
The U.S. Government says that you should ask for approval, and that has not been granted to date by the few brave souls that have tried. The U.S. crypto debate is well documented elsewhere.
This is an issue that you must address yourself using your own resources. You can try asking on the mailgroup, but please address your questions to other Americans who might have something to say.
If you do come up with a strategy that involves coding, feel free to talk to us about it. We can't comment on the workability of any particular solution - again, not being Americans, nor lawyers - but we can code up your requirements after some negotiation.
No, Cryptix has its own implementation of the RSA algorithm.
The patent on the RSA algorithm is only an issue for U.S. users, and maybe Canadians. Cryptix was originally written for non-North American usage, so that it is not an issue for most Cryptix users.
Attempts by U.S. users to license the patent have met with complete failure.
Note that there are alternatives to RSA. Note also that the patent expires in September 2000.
A licence from ASCOM may be required for commercial use of the IDEA algorithm. If your application does not use IDEA, then this should not apply. Alternative algorithms are provided.
The patent and legal aspects of this library will vary from country to country. Bert-Jaap Koops' Crypto Law Survey is an excellent summary, but for the final word you should seek professional advice locally.
With release 2.2 of Cryptix-Java and beyond, we have made a big effort to improve the documentation. There is is still a long way to go, but it's better than the official "sparse" rating that we earned on Adam Shostock's freeware crypto page. Pre-built and on-line browsable documentation is listed from the Mirrors. Cryptix-Perl remains sparse.
If you prefer to build the documentation using javadoc, first unzip the src.zip file that came with the JDK (if you haven't already done so), and set the JDK_SOURCE environment variable to that directory. Make sure the Cryptix source release is in the current directory, then run a script depending on your operating system:
- Under Unix, enter
JDK_SOURCE=/path/to/jdk/src sh util/makedocs.shReplace the first line above with "setenv JDK_SOURCE /path/to/jdk/src" for csh-like shells.
- Under NT or Windows 95 (from a command prompt), enter
set JDK_SOURCE=C:\path\to\jdk\src util\makedocsYou will need a reasonable amount of free memory to do this (about 12 MB).
See the compilation guide.
Before any of the Cryptix (3) algorithms can be used, Cryptix must be installed as a Security Provider. This involves adding a line to the java.security file:
security.provider.2=cryptix.provider.Cryptix
Replace '2' by the first unused provider number, if you have changed the java.security file before.
A program that will make this change automatically is supplied with the release. To run it, enter
java cryptix.provider.Install
Note that this program might not work
under OS/2. You will need to repeat this command for each new version
of the JDK (or other Java VM), that you install, but not for each new
version of Cryptix.
Whether you change the java.security file manually, or via the Install program, you will need permission to write to that file. This may cause problems in multi-user Unix environments where the JDK is installed in a shared directory that you do not have permission to change. In that case, you can either ask the system administrator to do the installation, or use the alternative installation method described next.
When distributing an application, it may not be convenient to require the user to install Cryptix (3) statically. In this case, you can use the following line in your application (before instantiating any algorithms) to achieve the same effect:
Security.addProvider(new cryptix.provider.Cryptix());
(If Cryptix is already installed statically, this will have no effect.)
Note that in an applet, this line will cause a security exception. We are planning changes to make it easier for applets to use the Security API without requiring extra privileges.
Cryptix 3.x only uses date/time-related calls for performance measurement in the test code. Since no other part of the library, including any of the cryptographic functionality, currently relies on date or time, Cryptix will continue to function correctly on any date for which the underlying Java VM and operating system does.
The calls used for performance measurement are 'new Date()',
'Date.toString()' and 'System.currentTimeMillis()'.
These might produce misleading results if the current time jumps
discontinuously while you are making a measurement (e.g. at daylight savings
transitions, or when the computer's clock is changed). This is arguably a
limitation of Java, in that there is no way to measure a duration
without getting confused by clock jumps. In any case, none of the cryptographic
functionality is affected.
Future planned features such as parsing of ASN.1 may have date-related code (for example, encoded ASN.1 can contain 2-digit year fields in some cases). This is likely to be handled using a fixed window from 1950 to 2049 inclusive when interpreting input. Any BER and DER output created by Cryptix will always use 4-digit year formats.
Note that development releases may contain code that has not been checked for date problems - the above statements are only guaranteed to apply to official releases.
A couple of people have flamed me about this, and others asked for more information, so let me elaborate just a bit. A virtual machine is a correct, working implementation of Java if and only if it implements exactly the behaviors set forward in the VM specification. That specification, intentionally, leaves anything that might be impossible to achieve on a particular platform open to interpretation. The API's, however, do not always make this explicit. A good example is theThread.sleep(long)call. The call is accurate to the millisecond. The VM does not require an implementation to have a clock accurate to the millisecond, or the ability to time threads that accurately.Those areas that are left "open" to implementation happen, not by coincidence, to be exactly the same areas that we rely on to get entropy: the interface between the deterministic, finite state machine in the computer and the non-predictable, infinite state real world. It is exactly those properties of non-predictability and infinite granularity of state that we use to get entropy. But precisely because every machine is built differently, and has a different interface to the real world, the VM spec does not assume one in particular.
For instance, it requires that every time a key is clicked, the peer with the focus gets an event. It does not specify if those events should be handled separately, or if when keys are being pressed rapidly they should all be packaged first then sent to the component in rapid succession. It specifies that when a Thread is killed, it gets a
ThreadDeathException; it does not specify exactly when this needs to occur. In most current implementations, it occurs when a call to native code returns.As a consequence of this, any code that relies on idiosyncrasies of a particular VM implementation, as all of the ideas so far put forward (and I believe all possible ways of getting entropy from the user) have, will not necessarily run on every other, or any other VM.
David Hopwood says:
The above makes the problem of obtaining random numbers in a Java VM sound worse than it is - the purpose of thejava.security.SecureRandomclass is to provide cryptographically secure random numbers, and it's the responsibility of each virtual machine implementor to ensure that the method that it uses to do that will work with their VM. In practice, the method used by Sun's implementation (counting the number of times a thread can yield in a given time) is IMHO reasonably well-thought out, and is likely to work at least on the Java VMs currently available from Sun and its licensees.Since it is not completely proven, though, Cryptix 3.1 and later will use the
/dev/randomdevice, on platforms for which it is available, as an additional source of seed data.
Cryptix 3.1, released July 1999 is a maintenance update to Cryptix 3.0.3, it features the following changes:
Version 3 also supports a more flexible trade-off between the performance of native code and the portability of Java: native versions of some algorithms are available for speed, but a Java version will be used if these are not present, or fail to load correctly. (Sun's "100% Pure Java" initiative specifically allows this approach for provider-based interfaces such as the Security API, although Cryptix has not yet been put forward for "100% Pure Java" certification.)
Some overhead is incurred by the IJCE being pure Java, but there is scope for significantly reducing this overhead in future versions, for cases where large amounts of data are encrypted. A great deal of attention has been paid to ensuring that the Cryptix native code does not introduce security problems through buffer overflows, incorrect memory management, race conditions etc.
The basic architecture for Version 3 is now well established, and work is progressing on new features. The next major change is likely to be support for JCE 1.2, the next version of Sun's Java Cryptography Extension.
Why don't the Cryptix-Java classes implement the Serializable interface?
There are a number of reasons. Here's David's list:
Can Cryptix be used in applets?
It depends. Generally, applets are code downloaded from a remote machine. They can therefore be intercepted and replaced as they travel from the remote machine to the local machine. Adding strong crypto of the sort included in Cryptix does not protect against this in any way, as it it would be relatively easy for an attacker to change the applet in some way (applets can be decompiled, and the crypto code is published) to disable or subvert the crypto.
This problem is lessened (not eliminated) when using an applet that has been authenticated. If all of the following conditions are true, it could be useful to rely on the Cryptix library in an applet:
The reason why Cryptix must be installed locally, apart from the
download time, is that some of its classes are in the java.security
package, and most browsers will not let applets define classes whose
names start with "java.".
HotJava's support for signed applets is (at the time of writing) more a proof-of-concept than anything else. In particular its key management is not currently robust enough to use for anything very significant [IMHO --David]. Netscape 4.0 is looking promising, but note that the first few releases of browsers that support signed applets are likely to have bugs in that support.
Most of the applications written to date require complete security over an insecure network, including the existence of aggressive attackers. It is for this reason that we are skeptical about the use of Cryptix for applets. Your mileage may vary.
What are all these references to native code in the source?
We originally planned to support native implementations of the various algorithms in Cryptix for performance reasons. The current Java Virtual Machines however are so fast that they render native code obsolete. The source code still contains the native code support framework but it is not used and will be removed in upcoming versions of Cryptix.
Why is the Java namespace as it is?
In older releases of Cryptix-Java (pre-2.2) there were elements of the classes inside the java.crypt, java.math and cryptix namespaces.
Cryptix-Java V2.2 migrated to a local hierarchy of cryptix:
Pre-2.2 2.2 java.math cryptix.math java.crypt cryptix.security java.crypt.rsa cryptix.security.rsa Table 3: Namespace changes in V2.2
Version 3.x has a completely different structure, and the three packages above have been deprecated:
3.0.x Description cryptix.provider.* The Cryptix security provider (split into subpackages for different types of algorithm) cryptix.util.* Support and utility classes (split into subpackages according to function, e.g. math, test, etc.) java.security.* The IJCE API netscape.* Dummy classes required for Netscape VM support Table 4: Namespace in V3.0.x
The International JCE implementation lives in java.security.* and java.security.interfaces.*, just like JavaSoft's early-access release. According to the JCE 1.2 preview APIs, the encryption classes (i.e. those that are not exportable from the U.S.) will move to javax.crypto, and IJCE will change to follow the same pattern.
A few notes on other choices follow.
Cryptix should live in its own namespace (as opposed to, for example, "systemics") because it is a community resource. A lot of the work in original coding was done by people on the net, and Systemics' main assistance is in packaging. The long term goal was always to have a team of developers maintain, update and publish it independently of Systemics. This goal has been mostly realised in the current release, which includes the substantial efforts of the Cryptix Development Team, as distinct from Systemics.
Another issue is the convention of COM.company as a namespace to guarantee uniqueness. The original developers of Cryptix have adamantly rejected this Berkeleyism in a general distaste of mixing namespaces arbitrarily. More specifically, the Cryptix Development Team don't yet have a unique (or otherwise) domain address, and might not in the future. Conspiracy theorists will also wish to note the strong causal link of TLAs from .COM to NIC to SAIC to NSA ...
Why is there a cryptix.math.BigInteger class, when the Java API supports built-in bignum arithmetic via java.math.BigInteger?
This class was needed by earlier versions of Cryptix designed for Java 1.0.x, before java.math.BigInteger was available. It is now deprecated, but our PGP still uses it. You can find it in the OLD.jar archive for use with applications written for Cryptix 2.2.
cryptix.math.BigInteger has
methods toJavaMathBigInteger and fromJavaMathBigInteger,
that can be used to convert from one format to another. This conversion
isn't terribly efficient, though.
Which Java platforms can Cryptix 3.x be used on?
Cryptix 3.0.4 and later require Java 1.1 or 1.2. Support for running on Java 1.0.2 has been dropped, because this was limiting development of new features.
Cryptix Release Java 1.0.2 Java 1.1.x Java 2 (JDK 1.2.x) Netscape 4.x 2.2 and earlier Yes Yes [3] Yes [3] Yes [3] 2.2.0a and 2.2.1 No Yes No No 3.0 - 3.0.3 No [4] Yes No [5] No [6] 3.1.x onward Not tested Yes Yes Not tested Notes:
- [3] Apart from a bug in the DES class, when compiled using a Java 1.1 compiler.
- [4] Cryptix 3.0 to 3.0.3 were able to run on Java 1.0.2 by adding classes from a JDK 1.1 release to the CLASSPATH.
- [6] Some users have been able to modify Cryptix 3.0 - 3.0.3 to work with Netscape.
Table 5: Java version requirements
The Cryptix 3.1.x releases have been built and tested on these Java platforms:
The Cryptix 3.0.x releases have been built and tested on these Java platforms:
Ciphers, message digests, modes, and some support classes for Cryptix 2.2 are now provided in the OLD.jar.
However, all of the classes that were in the 2.2 release are deprecated, and we recommend that you should port over to the IJCE (see the next section) as soon as possible.
Cryptix 3 introduces the International Java Cryptography Extension, or IJCE for short. This complete, clean room implementation of the Javasoft specification is intended to give plug & play crypto compatibility with Java crypto from many different suppliers of cryptographic algorithms.
The IJCE includes four general cryptographic APIs (but no implementations):
Onto the architecture of the IJCE, a provider can be plugged in to supply crypto algorithms such as IDEA, RSA and RIPEMD160 that meet the interface specification. In the Cryptix 3 releases, the Cryptix provider includes these algorithms and more plugged into the IJCE.
The JCE specification is open and there are other implementations. Also, it is envisaged that there will be many implementors of providers, using the IJCE as a platform, or other JCEs. It is our intention to be conformant with the specification, and seek to provide plug & play operation with other products.
To date, no compatibility testing has been conducted. As there are a number of ambiguities within the specification, some problems are to be expected. Watch this space.
When the compatibility testing is complete, other implementations of the JCE specification, such as JavaSoft's JCE implementation, will not conflict with Cryptix if they are installed in the classpath at the same time. For the current release, make sure that JavaSoft's JCE classes are not on the classpath.
Known differences from JavaSoft's version are listed here. Any English-writing journos out there to even the balance?
Uh, it would be immoral and highly naughty of us to tell you. But here are a few "facts":
The current implementation of El Gamal is very new, and would not be recommended for serious use just yet. ElGamal as an algorithm is somewhat newer than RSA (date?), but has been subject to a serious amount of attention, including by those at RSADSI, who are generally very careful to reveal shortcomings in competitive products :-)
Armed with the above pseudo-facts, there are some things you can do to check out the situation:
Here's how David Spector puts it:
Good, safe, well-tested cryptographic security software is like a flu vaccine. It must be extensively researched and tested to know in what kinds of situations (in the case of a vaccine, what strains of flu) it is appropriate to use and in which it is not. The ability of software to interoperate correctly with other similar software is one of these tests. Imagine a flu vaccine that kills you if you've ever had a polio or tetanus shot.
Just like vaccines and other medicines, high-quality cryptosystems go through a rigorous set of designs, reviews, trials and peer-reviews before they should be trusted with your data (or in the case of a vaccine, your life!).
A security system is not something you buy off the back of a truck, nor is it something that non-experts (such as faith healers or trade-magazine writers [or congressmen]) are likely to be expert at, so taking security advice from these so-called experts is a lot like going to a "psychic-surgeon"... you will probably not get what you expect, and most certainly will not get better if you are ill.
Finally, like medicines, cryptosystems need to be re-evaluated on a regular basis to ensure that they are still effective, and are still safe to use. Since technology (and the flu) is always on the move, it's a good idea to keep ones technology (and ones flu shots) up to date.
Here are vital statistics on some of the secret key algorithms included in various releases of Cryptix:
Algorithm Publication Year Pluses Minuses DES 1975 well tested key too short, slow Triple-DES n/a very well tested, conservative choice three times slower than DES IDEA 1991 PGP popularity commercial license required Blowfish 1994 fast en/decryption, popular slow key setup SPEED 1997 very fast, variable key/block/rounds very new, attacked in unpublished paper, no details available, but thought to be broken CAST5 1997 Conservative design, fast, PGP5 popularity newish LOKI91 1991 reviewed, undergoing update for NIST (LOKI97), very fast newish RC2 ? ? new RC4TM ? very fast stream cipher, tricky to use SAFER 1993 strengthened 1995 new Square 1997 fast very new Table 6: Vitally Secret Statistics
Notice the studied absence of a recommendation from the team :))
Some deeper comments on algorithms can be found in A Current Perspective on Encryption Algorithms by Laurie.Brown at adfa.oz.au.
The Block Cipher Lounge contains an index that directs the reader to current attacks on most current algorithms. This page is maintained by cryptographers Lars R. Knudsen and Vincent Rijmen.
For details on the support for each algorithm, see Supported Algorithms.
From time to time, an algorithm is shown by the cryptographic community to be broken. Sometimes concerns are raised, and at other times, simple flaws are rectified with simple fixes.
It is part of the responsibility of every crypto-programmer to be aware of these dynamic recommendations, and to respond in some fashion. This section discusses how we, in the Cryptix community, will attempt to respond to this challenge.
The working practice that we use is
This seems to best fit the particular roles, skills and needs of cryptographers, developers and users alike. It takes into account these considerations:
This is changing over time, and our cryptographic skill is improving, but our role of providing code is best kept independant of the cryptographic role of advising on good algorithms.
By separating the concerns of code from algorithm, we can hopefully be less biased.
The canonical example is DES. Even though this is a forgettable algorithm by all programming standards, it is endemic in the computing infrastructure. For this reason, support is unlikely to be dropped for a decade or more, but you should take every chance to migrate to something better.
Without a way to get new algorithms out there and being used, when by rights these algorithms have not been properly tested, there would be no way for any algorithm to become tested and acceptable.
To overcome this bootstrapping problem, we encourage cryptographers and users alike to try out new algorithms. And to take the knocks when they are broken, of course. In the long run, this will help to ensure a suitable supply of algorithms suitable for dynamic challenges on the Internet.
Please send any and all comments to the mailgroup.
Performance is not a big concern with Cryptix. Most hackers are concerned with getting code out there right now if not sooner. And most applications run on machines like PCs that these days munch through crypto as if it wasn't there.
However, there are still some good reasons for considering performance. Sometimes, you need to know whether your application needs to use the high performance options such as C or assembler - if you can get away without it this means big savings in complexity and hassle.
Performance programs make great examples, as they clearly show how to use the algorithm without getting into real-life considerations that tend to obscure things. It's also got to be said that speed of one's favourite algorithm is a competitive ego-inflating sport, of which we need many more on the Internet :))
What follows are those Cryptix Application Notes (CANs) that cover the issue of performance and tuning. Actually that is most of them but that is not really the issue ...
In CAN-1, author Raïf Naffah compares the speed of several hash functions.
In detail, CAN-2 compares the speed of several symmetric block ciphers.
To do.
If you are worried about performance, then you should really be using a high performance language like C for the algorithm itself. Real crypto-grinders like to hand code the inner loops in assembler, spending 100s of man-hours looking for savings of cycles. Of course, hardware is where it's really at...
If, however, you really want a faster algorithm in Java, CAN-3 describes how the author speeded up the LOKI91 algorithm by a factor of 20, taking it from the worst to the equal best.
Call
Security.addProvider(new cryptix.provider.Cryptix());
before using any algorithms. Also read this bug
entry.
Most of the RSA functions require a key size that matches or exceeds the length of data block that is passed. Some things will work with smaller keys, but for everything to work, use a minimum key size of 384 bits.
This not a bug, but a feature :)) It is also recommended by RSA themselves for some of their products.
This property of RSA also means that if you try to encrypt a piece of data twice with different public keys of the same bit length, and the second key is less than the first, the result will not necessarily decrypt correctly if the corresponding private keys are used in reverse order. This is also not recommended because there may be cryptanalytic attacks that apply only to this kind of multiple encryption.
A better way of doing multiple encryption in series (where both of two private keys are needed to decrypt), is to generate two random secret keys for a symmetric algorithm, encrypt these separately using the public keys, and encrypt the plaintext using each secret key in turn. I.e. the result will be the three values:
To distinguish, these are generally called SHA-1 and SHA-0. The variant SHA-1 is based on a suggestion made by the NSA, and is widely thought to be slightly better. It is recommended.
In Cryptix 3, you would normally construct these message digests using
"SHA" can be used as an alias for "SHA-1".MessageDigest.getInstance("SHA-1"), or
MessageDigest.getInstance("SHA-0").
Sorted with most recent first.
When using Sun's implementation of JCA (as Cryptix versions 3.0 to 3.0.3
inclusive do) with JDK 1.1, providers that have been added dynamically
(i.e. using Security.addProvider) might be uninstalled as your
program is running, leaving only the providers specified in the
java.security file.
This is a result of JDK 1.1 not correctly implementing the language specification for class unloading (as clarified at http://www.javasoft.com/docs/books/jls/clarify.html) - in particular it will sometimes unload classes loaded by the default ("system") classloader.
If the java.security.Security class is unloaded, the static
fields of that class, including the field that holds the list of installed
providers, will be lost. When the class is reloaded, only the providers in
the java.security file will be reinstalled.
A workaround is to put
private static final Class workaround = java.security.Security.class;in your main class. This will make sure there is a reference to the
java.security.Security class at anytime.
If a cipher with a variable block size (e.g. SPEED) is set to a block size larger than the default, and is used in a mode other than ECB, an ArrayIndexOutOfBoundsException will be thrown when data is encrypted or decrypted. This happens because the array created to store the initialisation vector is created before the block size has been set, and is not long enough to store an actual block.
A fix for this problem will be included in Cryptix 3.0.4.
In Cryptix 3.0 to 3.1.0 inclusive, the comments for Cipher.engineUpdate (and
implementations of that method in cipher and mode subclasses), say that the in and
out parameters may be the same array, and that the input and output regions may
overlap. For some algorithms (e.g. RSA, and the mode CBC), the code for
engineUpdate would not be correct under that assumption.
In fact the comments need to be changed; IJCE's implementation of the Cipher class
will ensure that cipher and mode engineUpdate methods are never called
with overlapping input and output regions.
It has been agreed on a mailing list for JCE implementors that the Cipher class should do this, but at the moment, we do not recommend that the Cryptix provider be used with any JCE implementation other than IJCE.
Cipher.getInstance("ElGamal") will throw an exception, for example:
java.lang.IllegalArgumentException: IJCE does not support ciphers for which implPadding == true
at java.security.Cipher.(Cipher.java:290)
at cryptix.provider.elgamal.RawElGamalCipher.(RawElGamalCipher.java:79)
at java.security.IJCE.getImplementation(IJCE.java:357)
at java.security.Cipher.getInstance(Cipher.java:476)
at java.security.Cipher.getInstance(Cipher.java:439)
at java.security.Cipher.getInstance(Cipher.java:382)
at [...]
The ElGamal cipher implementation is experimental code, and is not yet supported
or tested (it should not really have been enabled in the Cryptix.properties file).
ElGamal will not be fixed in Cryptix V3. Our upcoming JCE will contain a working ElGamal implementation.
This library includes, or is derived from software developed by (and owned by) the following:
The Cryptix Development Team
Other contributors
Do not mail these people (either from the Cryptix Development Team or external contributors) with requests for help. Some of them have never even seen Cryptix, and the rest worked on very specific parts. Joining the mailgroups is the only way to seek help.
As software, Cryptix is owned by the programmers who wrote the original code. This is a diverse group of developers across the net, of which programmers in the Cryptix Development Team are the majority, but not the only contributors.
As a brand name and trademark, Cryptix is owned by Systemics. The use of the Cryptix trademark is a mechanism to assert rights over the product, and protect it from fraudulent attribution claims. Systemics asserts these rights on behalf of the owners (the developers) although it doesn't seek to own each line of code. The individual developers rights are in addition to and are not superceded by any rights that Systemics asserts under the Cryptix License, below.
Copyright © 1995-1999 Systemics Ltd (http://www.systemics.com/) on behalf of the Cryptix Development Team (http://www.cryptix.org/). All rights reserved.
This library and applications are FREE FOR COMMERCIAL AND NON-COMMERCIAL USE as long as the following conditions are adhered to.
Copyright remains with Systemics Ltd, and as such any Copyright notices in the code are not to be removed. If this code is used in a product, the Cryptix Development Team should be given attribution as the author of the parts used. This can be in the form of a textual message at program startup or in documentation (online or textual) provided with the package.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
The licence and distribution terms for any publically available version or derivative of this code cannot be changed, i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence].
Sun, JavaSoft, JDK, Java, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc.
Microsoft, Windows 95 and Windows NT are registered trademarks of Microsoft Corp.
Irix is a registered trademark of Silicon Graphics, Inc.
RC4 is a trademark of RSA Data Security, Inc.
Other brand, product, and algorithm names may be trademarks or registered trademarks of their respective holders.
Copyright © 1995-1998 Systemics Ltd