We Keep Coding

How can I get the same number of bytes in Java vs a tad outdated Swift code?

I am trying to get the same amount of bytes of the below snippet in Java. I am working with decryption of encrypted strings with known key. However, I am unable to reproduce these two lines of code in Java.
let usrKey: NSData! = (usrKey as NSString).data(using: String.Encoding.utf8.rawValue) as NSData!
let keyBytes = UnsafeMutableRawPointer(mutating: usrData!.bytes)
How can I get the same keyBytes in Java?
What will the equivalent expression of the above in Java language?
What is the behavior of mutating ?
Java code I tried working with and the error below that.
byte [] keyBytes = userKey.getBytes("UTF-8");
SecretKeySpec secret = new SecretKeySpec(keyBytes, "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.DECRYPT_MODE, secret, newIvParameterSpec(ivBytes));
byte[] outputBytes = cipher.doFinal(inputBytes);
input 16 bytes
iv 16 bytes
key 32 bytes
ALGORITHM - AES128/CBC/PKCS5Padding
Exception in thread "main" javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:991)
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:847)
at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446)
at javax.crypto.Cipher.doFinal(Cipher.java:2164)
The issue is to find the right way to get the user key (could be short so padded) and create similar 32 bytes (required by the decryption algo) between Swift and Java code.

The Java line
byte [] keyBytes = userKey.getBytes("UTF-8");
should have the same effect as the two Swift lines. The problem is likely outside of the code that you showed in the question. You may want to debug both Swift and Java code to make sure the usrKey matches userKey and that the resulting keyBytes are the same in both Swift and Java.
Please see Apple documentation at https://developer.apple.com/documentation/swift/unsafemutablerawpointer/2427850-init for the meaning of mutating. Also consult Apple documentation for any other API-related questions.

Translating Java RSA encryption routine to Objective-C

I am trying to duplicate an encryption process that is working in Java over to iOS/OSX.
My Java code is as follows:
PublicKey publicKey = KeyFactory.getInstance("RSA").
generatePublic(new RSAPublicKeySpec(firstKeyInteger, secondKeyInteger));
// This always results in the public key OpenSSLRSAPublicKey{modulus=2b3b11f044.....58df890,publicExponent=10001}
Cipher cipher = Cipher.getInstance("RSA/ECB/OAEPWITHSHA1ANDMGF1PADDING");
String stringToEncode = "EncodeThisString";
byte[] bytesToEncode = stringToEncode.getBytes("UTF-8");
cipher.init(cipher.PUBLIC_KEY, publicKey);
byte[] encrypted = cipher.doFinal(plain);
The first challenge i'm struggling with is how to use the public key in iOS. Can I just dump the modulus into NSData and use it? Or must I store it in the keychain first? (I don't really need to use the keychain unless I must). Or is there a method similar to generatePublic() were I can recreate the public key using the 2 integers?
Then would I use SecKeyEncrypt to encrypt? Whenever I add this to my project I get Implicit declaration warnings even though I import the Security framework.
Thanks
EDIT -----
I think I have managed to get a Base64 encoded public key, which I believe is what is in a PEM certificate. Now, how to use it.

Obfuscate Strings

we use some Networkcredentials in out App. I just decompiled the app and was able to see the Credentials like Name and Password. I do not really get how to prevent this. I think the word "obfuscator" is the direction which I have to go.
We test proguard but it does not have string encryption or am I wrong?
Is there an easy and free way to do this?
Thank you.

Sorry, but this simply does't work no matter what you'll try. If you obfuscate / encrypt the credentials, the program still must be able to decrypt them at run-time. Therefore, the encryption keys must also be in the generated bytecode somewhere and therefore it's possible to take them, and decrypt the credentials manually outside the program (or just step through the program and read the credentials once they're decrypted).
What you're trying to do is Security by Obscurity and it doesn't work.
Whatever you do, if the program can obtain the credentials at run-time without any external help, a skilled attacker can do the same given enough time.
What you should do:
Store the credentials in plain-text in a property file. Don't bother with encryption, it's pointless. You must make sure the db user you're using is read-only or add-only or something similar so you prevent any damage.
Let the user input the password. If it's not stored in the bytecode, it's safe. He could e.g. input his password and have an account in the db...
Use a safe and known authentication mechanism. Plaintext login+password is not that.
Don't let your application go anywhere near a DB. Set up a service somewhere, with an API, which would hold the read DB conenction. Your application could connect to that and get data via this API. This way, an attacker can't directly access your DB. He could call anything in the new service, though, so you must make sure there's no sensitive data accessible in there.

You should consider to encipher the username and the password: How to encrypt String in Java.
// bytes to encrypt
byte[] input;
// the key and the initialization vector
byte[] keyBytes;
byte[] ivBytes;
// initialize the Cipher
SecretKeySpec key = new SecretKeySpec(keyBytes, "DES");
IvParameterSpec ivSpec = new IvParameterSpec(ivBytes);
Cipher cipher = Cipher.getInstance("DES/CBC/PKCS5Padding");
// encryption
cipher.init(Cipher.ENCRYPT_MODE, key, ivSpec);
byte[] encrypted= new byte[cipher.getOutputSize(input.length)];
int enc_len = cipher.update(input, 0, input.length, encrypted, 0);
enc_len += cipher.doFinal(encrypted, enc_len);
// decryption
cipher.init(Cipher.DECRYPT_MODE, key, ivSpec);
byte[] decrypted = new byte[cipher.getOutputSize(enc_len)];
int dec_len = cipher.update(encrypted, 0, enc_len, decrypted, 0);
dec_len += cipher.doFinal(decrypted, dec_len);
Usually, the key (bytes array) should be stored in a file that is only accessible on the specific instance where the server is running and not coded into the app source file.
Otherwise you can use hash (e.g: md5 or sha1) and store the fingerprint instead of the plain string:
// SHA1("hello world") -> "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed
This is a simple method which allows you to calculate the SHA1 hash of a string:
public static String SHA1(String text) throws NoSuchAlgorithmException, UnsupportedEncodingException {
MessageDigest md = MessageDigest.getInstance("SHA-1");
md.update(text.getBytes("iso-8859-1"));
byte[] hash = md.digest();
Formatter formatter = new Formatter();
for (byte b : hash)
formatter.format("%02x", b);
return formatter.toString();
}
Import java.io.UnsupportedEncodingException, java.security.MessageDigest and java.security.NoSuchAlgorithmException are required.

Your issue is related to encryption and not obfuscation. You may use this library to store the credentials in an encrypted way: http://www.jasypt.org/encrypting-configuration.html
There are different ways to pass the encryption key to it.
Otherwise, depending on your context, consider using different authentication mechanisms (SSO like) instead of login/password.

ruby to android 3DES encryption - pad block corrupted

I am trying to encrypt a string in ruby and descrypt in Android. I'm pretty unfamiliar with ciphering, but I've done some reading and I think I'm close to getting to work. however, I'm still getting an error on the Android side that I just do not understand how to fix. I understand what padding is and that it's not correct, but what do I need to change to make this work? My ruby and java code are below. Thank you!!!
Ruby:
shared_key = "123456789012345678901234"
cipher = OpenSSL::Cipher::Cipher.new("des3")
cipher.encrypt
cipher.key = shared_key
ciphertext = cipher.update(secret)
ciphertext << cipher.final
Rails.logger.debug(ciphertext);
encrypted_secret = Base64.encode64(ciphertext)
Rails.logger.debug(encrypted_secret);
render json: { 'token' => token, 'secret' => encrypted_secret }, status: :ok
Java:
SecretKey key = new SecretKeySpec(SHARED_DECRYPTION_KEY.getBytes("UTF8"), "DESede");
byte[] encryptedSecretBytes = Base64.decode(secret);
Cipher cipher = Cipher.getInstance("DESede"); // cipher is not thread safe
cipher.init(Cipher.DECRYPT_MODE, key);
byte[] plainTextSecretBytes = (cipher.doFinal(encryptedSecretBytes));
String decryptedSecret = Base64.encodeBytes(plainTextSecretBytes);
and the exception I get in Android:
05-14 19:03:11.500: W/System.err(22175): javax.crypto.BadPaddingException: pad block corrupted
05-14 19:03:11.500: W/System.err(22175): at com.android.org.bouncycastle.jcajce.provider.symmetric.util.BaseBlockCipher.engineDoFinal(BaseBlockCipher.java:709)
05-14 19:03:11.500: W/System.err(22175): at javax.crypto.Cipher.doFinal(Cipher.java:1111)
05-14 19:03:11.500: W/System.err(22175): at com.cdlcollege.saas.Credentials.storeServerAccessCredentials(Credentials.java:85)

Pad block corrupted means the wrong key was used to decrypt or the data was altered between encryption and decryption.
If I had to guess, I suspect you are creating a key in the wrong manner. Instead of calling getBytes(), I'm guessing you should have done a hex conversion.
See Convert hex string to byte [] for example Android code for performing this task.
Side note: don't just specify "DESede" for a cipher. Specify the mode and padding as well. E.g. "DESede/CBC/PKCS5Padding". That ensures you get exactly what you want, rather than crypto provider defaults (which may vary across phones).

IVParameter Spec Problem in Java

I am currently devloping a Windows application using C# and looking at developing a mobile app using Java.
The windows software and the mobile app will work together, the windows app will store information and encrypt certain information before storing it in an online database.
The mobile app will pull the information from the online database and will need to decrypt the encrypted string that is retrieved from the datbase.
The encryption method I am using in C# is below
byte[] clearTextBytes = Encoding.UTF8.GetBytes(encryptionString);
SymmetricAlgorithm rijn = SymmetricAlgorithm.Create();
MemoryStream ms = new MemoryStream();
byte[] rgbIV = Encoding.ASCII.GetBytes("ryojvlzmdalyglrj");
byte[] key = Encoding.ASCII.GetBytes("hcxilkqbbhczfeultgbskdmaunivmfuo");
CryptoStream cs = new CryptoStream(ms, rijn.CreateEncryptor(key, rgbIV), CryptoStreamMode.Write);
cs.Write(clearTextBytes, 0, clearTextBytes.Length);
cs.Close();
return Convert.ToBase64String(ms.ToArray());
The Windows method works fine.
The code I am using in Java is as follows:
KeySpec ks = new DESKeySpec("hcxilkqbbhczfeultgbskdmaunivmfuo".getBytes("UTF-8"));
SecretKey key = SecretKeyFactory.getInstance("DES").generateSecret(ks);
String ivString = "ryojvlzmdalyglrj";
byte[] ivByte = ivString.getBytes("UTF-8");
IvParameterSpec iv = new IvParameterSpec(ivByte);
//RC5ParameterSpec iv = new RC5ParameterSpec(ivByte);
Cipher cipher = Cipher.getInstance("DES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, key, iv);
byte[] encoded = cipher.doFinal(Base64.decodeBase64("iNtaFme3B/e6DppNSp9QLg=="));
Log.d("Decoded Password", encoded.toString());
As both methods need to encrypt and decrypt the same string together it has to use the same key and IV. The only problem that I am having is in the java method the IVParameterSpec is going into the catch with an error that says IV must be 8 bytes long.
How can I resolve this to ensure that I have the same IV as C#.
Thanks for the help

The problem is that you are encrypting (in C#) with AES (also known as Rjindael), but trying to decrypt in Java with DES. If you change your Java code to use AES then it should all work fine.
DES uses an 8-byte IV because it works on 64-bit blocks. AES uses a 16-byte IV because it works on 128-bit blocks.
You should also make sure you use the same character encoding. In C# you are using ASCII, but in java you're using UTF-8. In your case they will be the same, but you should really fix it now to prevent strange bugs in future. You can change the character set name in Java to "US-ASCII" and it'll work.

You have to use the same algorithm of course. The default algorithm is for .NET is AES, so that is what you should be using on the Java side as well.