We Keep Coding

Given a KeyPair, how can I verify that the keys contained in this KeyPair are the expected length?

I am writing some Junit tests in which a number of objects of type java.security.KeyPair are generated (from a java.security.KeyPairGenerator)
I am adding some asserts to confirm that the keys contained in these KeyPairs have the expected attributes (the expected algorithm and the expected sizes).
For example, I have added an assert statement to confirm that the algorithm is the expected algorithm using:
String expectedAlgorithm = "RSA";
String errorMsg = "The key is not of the expected algorithm";
assertEquals(errorMsg, expectedAlgorithm, privateKey.getAlgorithm());
I tried to find some method in KeyPair or in the Keys themselves which returns the size (number of bits) of the keys but I could not find such a method.
I checked the output of the toString() method of the keys to see if this string contains the size of the keys, using:
String stringRepresentation = publicKey.toString();
I found that for the SunRsaSign provider, the string contains the number of bits in its first line (and therefore it is possible to confirm the key size by parsing this String. But then when I checked the same method for Bouncy Castle, I found that the string does not contain the number of bits. As shown below:
Output of toString() on a key from the RsaSunSign Provider:
Sun RSA public key, 1024 bits
modulus: 10827493886854...
public exponent: 65537
Output of toString() on a key from the Bouncy Castle Provider:
RSA Public Key
modulus: 830d0eb805c527e8...
public exponent: 10001
So it is obviously not safe to use the output of the String representation of a key to confirm its size, as we cant know which provider will be used.
So my question is: given a KeyPair (and also given the KeyPairGenerator that was used to generate that KeyPair), is there a provider-neutral way to confirm the size of the Keys in the KeyPair?

The size of an RSA key is defined as the number of bits in the modulus. Note that the modulus is generated in such a way that it is in between 2 ^ (n - 1) and 2 ^ n - 1 (inclusive), so it cannot be smaller than the key size.
So to get the key size of a public or private RSA key, you do the following:
int keysize = RSAPublicKey.getModulus().bitLength();
You may have to (down)cast your PublicKey or PrivateKey to RSAPublicKey and RSAPrivate key before you can access the modulus.
Usually the bit size is on a byte boundary, i.e. the bit size can be divided by 8.

SHA256withRSA what does it do and in what order?

I'm a total newbie when it comes to cryptography and such things. I don't (and dont want to) know the details of the SHA256 and RSA. I "know" what they do, not how they do it, and for now that's enough.
I'm wondering what the "SHA256withRSA"-algorithm (if you can call it that) actually do and in what order. For example, does it hash the data with SHA256 and then encrypts it using RSA or is it vice-versa, or something else?
The reason I'm asking is because I wanna do the java equivalent of:
Signature.getInstance("SHA256withRSA")
signature.initSign(privateKey); //privateKey == a key extracted from a .p12 file
in Objective-C on iOS. And I couldn't seem to find any stuff that does exactly this, therefore I'm asking, can I just hash the data (SHA256) and then encrypt it (RSA) (or vice-versa) and get the same behavior?
What is the suggested solution for doing this kind of thing?
Thank you!
EDIT:
I failed to mention that I sign the data using a private key that is obtained by doing:
KeyStore keystore = KeyStore.getInstance("PKCS12");
keystore.load(new FileInputStream(new File(filename)), password.toCharArray());
PrivateKey privateKey = (PrivateKey)keystore.getKey(alias, password.toCharArray());
Where filename is for example: "/somewhere/mykey.p12".

"SHA256withRSA" implements the PKCS#1 v1.5 padding and modular exponentiation with the formal name RSASSA-PKCS1-v1_5 after calculating the hash over the data using SHA256.
So the general order is:
hashing;
padding the hash for signature generation;
modular exponentiation using the private exponent and the modulus.
The padding used for encryption and signature generation is different, so using encryption may result in erroneous signatures.
The PKCS#1 v1.5 padding scheme has been superseded by PSS. For new protocols it is advisable to use the PSS scheme instead. For RSA a very readable public standard exists. This standard has also been used as a base for RFC 3447: Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 (which is basically a copy).
With regards to the padding in iOS, please check this answer by Thomas Pornin. Basically you should create the SHA-256 hash, prefix a static block of data (defined in the PKCS#1 specifications) then use SecKeyRawSign using kSecPaddingPKCS1.
For your convenience, the PKCS#1 defined block of data that needs to be prefixed in hex notation for SHA-256 (it can be bit hard to find in the standard documents, it's in the notes of section 9.2):
30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
Notes:
The above steps do not include the conversion from bytes to integer and vice versa. The result of raw RSA operations are generally converted to an unsigned big endian encoding with the same size of the modulus in bytes (which is generally the same as the key size, as the key size is already a multiple of 8). These conversions are called I2OSP and OS2IP in the RFC's.

Java - Converting string into DES key

I have been given a key as a string and an encrypted file using DES. That is all I know. I don't know how the key was encoded.
There is also a des.exe that I can use to decrypt, this is all I found on the Internet: http://knowledge-republic.com/CRM/2011/07/how-to-decrypt-extract-recreate-thecus-storage-firmware/
Using des.exe, the only command it works with is "-D", not "-d".
My goal is to use Java to do the same thing. I copied and pasted this from somewhere
String key = "blah";
DESKeySpec dks = new DESKeySpec(key.getBytes());
SecretKeyFactory skf = SecretKeyFactory.getInstance("DES");
SecretKey desKey = skf.generateSecret(dks);
System.out.println(desKey);
Cipher cipher = Cipher.getInstance("DES"); // DES/ECB/PKCS5Padding for SunJCE
if (mode == Cipher.DECRYPT_MODE) {
cipher.init(Cipher.DECRYPT_MODE, desKey);
CipherOutputStream cos = new CipherOutputStream(os, cipher);
doCopy(is, cos);
}
and it doesn't work.
What are some other options in converting a string into a key?
Should probably add I'm a complete newb at cryptography.

The SunOS man page for des (which seems to be what your des.exe is based on?) indicates that they key is generated like this:
The DES algorithm requires an 8 byte key whose low order bits are assumed to be odd-parity bits. The ASCII key supplied by the user is zero padded to 8 bytes and the high order bits are set to be odd-parity bits. The DES algorithm then ignores the low bit of each ASCII character, but that bit's information has been preserved in the high bit due to the parity.
It also mentions that the initial IV is always zero'd out, no matter what mode you are running in
The CBC mode of operation always uses an initial value of all zeros
for the initialization vector, so the first 8 bytes of a file are
encrypted the same whether in CBC or ECB mode.
It also mentions that the padding used is such that the last byte is always a value from 0-7, indicating the number of padding bytes used. This is similar to PKCS5Padding, so perhaps that would work
Since the CBC and ECB modes of DES require units of 8 bytes to be
encrypted, files being encrypted by the des command have 1 to 8 bytes
appended to them to cause them to be a multiple of 8 bytes. The last
byte, when decrypted, gives the number of bytes (0 to 7) which are to
be saved of the last 8 bytes. The other bytes of those appended to the
input are randomized before encryption.
Based on the options you indicated you are using, it sounds like you are using DES/CBC/PKCS5Padding for the cipher.
I think that just leaves determining how to actually derive the key. I found this sample code on exampledepot which might work for you. I think you would just need to convert your string password into 8 bytes (1 byte per character, so no UTF encodings) then stuff it through the code in the example to derive the key. Its worth a shot anyway.

DES keys are 7 (apparently SunJCE uses 7?) or 8 bytes. Check if the string you have been provided is 7 or 8 bytes. If so, then the chances are good it's the raw key. If not, it could be encoded in some fashion. A giveaway for hex encoding would be a prefix of 0x or suffix of h, and all characters would be in the range 0-9,A-F. You can certainly convert from hex yourself or use some code on the web, but I usually use an Apache commons lib (http://commons.apache.org/codec/apidocs/org/apache/commons/codec/binary/Hex.html).
That said, this is really speculation and I'm not sure we can jump to the conclusion that it's a problem with the key alone. Do you have any other info on the purported encryption algorithm? If the executable you cited works with "-d" then it seems like the encryption is plain DES in CBC mode:
-b : encrypt using DES in ecb encryption mode, the defaut is cbc mode.
(there are multiple possible modes, see http://download.oracle.com/javase/1.4.2/docs/guide/security/jce/JCERefGuide.html#AppA)
I would try setting your cipher to "DES/CBC".
Then again, I'm not sure how to interpret this:
Default is tripple cbc
You may be able to use this snippet to tell what ciphers are available on your system: http://www.java2s.com/Code/Java/Security/ListAllProviderAndItsAlgorithms.htm

I had the same issue with C#. I solved it in the end. You can have a look at my answer here: DES Initialization Vector in C#
Generally, what des.exe does, is that it computes a checksum using DES. So each encryption step is using the previous result instead of advancing in the output array.

Encrypt an Integer Value with DES

I want to encrypt an integer with DES, the resultant cipher text should also be an integer.
Decryption function should follow this notion as well.
I am trying to modifying the code at Encrypting a String with DES, by converting the byte array to integer, instead of using Base64 encoding. However the decryption function throws an exception of improper padding, as the conversion of integer to byte[] results in a 4 byte array.
Is there any other encryption algorithm that I can use to achieve this.
I am not concerned about the weakness of the cipher text.

If you are running an Integer value through DES to produce another Integer value, and you don't care about the cipher text weakness, then you are merely doing a very expensive hashing operation. You'd be better off generating a random integer as the key and bitwise xor-ing the exponent and the random integer. This would take nanoseconds to compute and have exactly the same security.

DES has a 64 bit blocksize, so in general the output from the encryption of a 32 bit int will be a 64 bit block. It will be easier to encrypt a 64 bit long to another 64 bit long. Use ECB mode so that padding is not an issue, or at least you are adding zero bits to the front of your int to extend it to 64 bits.
If you merely want to smush up your int then Jim's suggestion is excellent.

You want to look at Format Perserving Encryption. There are a couple of techniques for it, but in general all of them will generate a value in the same domain as your input ( i.e. integers, credit card numbers,etc)

Encryption and Java, method generating key - what size?

I got the following method body to generate a key for encryption:
new BigInteger(500, new SecureRandom()).toString(64);
Could anyone explain what is the size of generated key?

It's a secure random number with a length of 500 bit in your case. Have a look at the javadoc of the BigInteger(int numBits, Random rnd) constructor.

Your line of code creates a 500 bit integer and apparently tries to convert it to a String in Base64 - that's the toString() call. But that won't work, because BigInteger.toString() only works up to base 36 and defaults to decimal otherwise. If you need a Base64 representation, you have to use a third-party class, as there is AFAIK no Base64 encoder in the standard API.

Normally you would want your encryption key to be a power of 2. So perhaps you mean 512 bits?

First, as other suggested, you will get IllegalArgumentException because BigInteger doesn't support radix 64.
Even if you use a valid radix, the number of characters generated varies because BigInteger strips leading 0s and you might also get minus sign in the string.
To get random keys, just use random bytes directly. Say you want 128-bit (16 bytes) AES key, just do this,
byte[] keyBytes = new byte[16];
new SecureRandom().nextBytes(keyBytes);
SecretKey aesKey = new SecretKeySpec(keyBytes, "AES");