We Keep Coding

How to add negative number in byte into buffer

I have a problem with encoding a password in java and nodejs.
After I encode the password, I get the same result with javacode and nodejs.
result = [69, 83, 53, 95, -77, -40, -124, 109, 38, -85, 91, -105, 72, -61, 84, 54].
Then I convert it into a buffer in nodejs.
When i use crypto. I have use a method:
const content = 'et'
key = buffer.from(result)
const iv= Buffer.alloc(0)
crypto.createCipheriv("aes-128-ecb", key, iv)
let encrypted = cipher.update(content, "utf8", "base64");
encrypted += cipher.final("base64"); //result: Rrx7BNH5l/miPfFbGgAkMA==
I get a result that is different from the javacode
My java code
String content = 'et'
SecretKeySpec key = new SecretKeySpec(enCodeFormat, "AES");
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.DECRYPT_MODE, key);
byte[] result = cipher.doFinal(content);
system.out.printLn(Base64.encode(encryptResult)) //result:TJ4Z8bGSoJKiRFHwE929mg==
I think This problem occurs when converting the bytes into a buffer. So if array don't have negative number I'll get the correct result.
Please help me any solution

How to pass AES String crypted through HTTP header using javax.crypto

In one of our internal software we're implementing a new API endpoint which must be accessed by external sources through the internet and then it must be secured in some way.
Since we're not allowed to use library as OAuth or public and private keys we choosed javax.crypto AES to crypt out a "custom authorisation token" in each external source by this way:
...
Key aesKey = new SecretKeySpec("API-KEY".getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, aesKey);
byte[] applicationIdEncrypted = cipher.doFinal(applicationId.getBytes());
...
The token contains a custom applicationId to identify on the other side who's contacting that endpoint.
Since we must perform an HTTP call, we're converting applicationIdEncrypted into a base64 String
String base64Encoded = Base64.getEncoder().encodeToString(applicationIdEncrypted);
ON THE OTHER SIDE
We're getting the header and decode it from base64
String base64Decoded = new String(Base64.getDecoder().decode(header));
But when attempting to perform the last operation
Key aesKey = new SecretKeySpec("API-KEY".getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.DECRYPT_MODE, aesKey);
String headerDecoded = new String(cipher.doFinal(base64Decoded.getBytes())); //<- THIS
We got javax.crypto.BadPaddingException: Given final block not properly padded
Both base64Encoded and base64Decoded have the same value in both of the ends.
Attempting to perform the same operation in one of the ends (to not use the HTTP channel) no exception is thrown -but- a different headerDecoded is returned by the new String(cipher.doFinal(base64Decoded.getBytes()));
Looked for the bytes applicationIdEncrypted and base64Decoded.getBytes() and they're slightly different:
applicationIdEncrypted
[-28, -103, 107, 70, -112, 121, 4, -14, -80, -114, -14, 92, -81, -13, -128, 97]
base64Decoded.getBytes()
[-28, -103, 107, 70, 63, 121, 4, -14, -80, -114, -14, 92, -81, -13, -128, 97]
I read that maybe passing from bytes to String could be a loss of informations (maybe?) but I cannot figure it out why of this behaviours since both base64Encoded and base64Decoded have the SAME value in both cases and scenarios.
How can I achieve the passage of a "custom authorisation token" using only Java 1.7 javax.crypto libraries?
EDIT
The "API-KEY" is something like 02E30E6BE24BF1EA

As #James K Polk says, I had a mess with the thousand of String conversion so I managed to have a cleaner code first for a better comprehensive code.
ON THE CLIENT
Key aesKey = new SecretKeySpec("API-KEY".getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, aesKey);
byte[] applicationIdEncrypted = cipher.doFinal(applicationId.getBytes());
byte[] base64Encoded = Base64.getEncoder().encode(applicationIdEncrypted);
String out = new String(base64Encoded);
where out is the only one conversion in String and it's the HTTP header's payload.
ON THE OTHER SIDE
byte[] in = out.getBytes();
byte[] base64Decoded = Base64.getDecoder().decode(in);
Key aesKey = new SecretKeySpec("API-KEY".getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.DECRYPT_MODE, aesKey);
byte[] applicationIdDecrypted = cipher.doFinal(base64Decoded);
String applicationId= new String(applicationIdDecrypted);
I had ONLY two conversion into String: out (the header's base64 value) and applicationId.
In this way I used to have the same applicationId value.

JAVA AES 256 Decrypt [duplicate]

This question already has answers here:
InvalidKeyException Illegal key size
(6 answers)
Closed 6 years ago.
I'm trying to decrypt with AES some data. I've been given a 256 bit key and 16 byte IV like these:
String key = "Hh1s1f4T2mpN3yCh4ngeL8t3r\\.Thxpp";
int[] v = {11, 1, 555, 222, 241, 21, 11, 33, 35, 91, 45, 6, 14, 30, 22, 234};
String IV = Arrays.toString( v );
I've been told the padding should be PKCS7 but when I init the cipher with AES/CBC/PKCS7PADDING it says: Cannot find any provider supporting AES/CBC/PKCS7PADDING
If I use AES/CBC/PKCS5PADDING I get Illegal key size but I've checked that the key size is 32.
public static String decrypt(String key, String initVector, String encrypted) {
try {
System.out.println( "Key size: " + key.getBytes("UTF-8").length );
IvParameterSpec iv = new IvParameterSpec(initVector.getBytes("UTF-8"));
SecretKeySpec skeySpec = new SecretKeySpec(key.getBytes("UTF-8"), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5PADDING");
cipher.init(Cipher.DECRYPT_MODE, skeySpec, iv);
byte[] original = cipher.doFinal(Base64.decodeBase64(encrypted));
return new String(original);
} catch (Exception ex) {
ex.printStackTrace();
}
return null;
}

If you are getting an IllegalKeySize exception with AES-256, check to ensure you have the JCE Unlimited Cryptographic Strength Policy files installed in your active JVM. They are required for any AES key length over 128 bits.
(PKCS #7 padding scheme is effectively equivalent to PKCS #5 in Java (the block size differs in the spec definitions), but Java never added the PKCS #7 name to its list, so using PKCS5Padding is correct.)

First see the answer by #Andy.
If you are getting an "Illegal key size" error then the key size is incorrect, you need to figure out why by debugging. Create a variable for the UTF-8 key
byte[] keyBytes = key.getBytes("UTF-8")
and display it as hex, that way you can see exactly what it happening.
Inline conversions are essentially impossible to debug.
PKCS#5 padding is a subset of PKCS#7 padding and in every instance it is the same, PKCS#5 is just a name holdover from DES by lazy developers.
PKCS#7 padding:
PKCS#5 padding is identical to PKCS#7 padding, except that it has only been defined for block ciphers that use a 64-bit (8 byte) block size. In practice the two can be used interchangeably.

You need to use bouncy castle as a provider for PKCS7PADDING.

Android DES algorithm default attributes

I am using following code for encryption in Android project:
SecretKeyFactory kf = SecretKeyFactory.getInstance("DES");
String key = "abcdefg";
DESKeySpec keySpec = new DESKeySpec(key.getBytes());
SecretKey _key = kf.generateSecret(keySpec);
String xform = "DES";
Cipher cipher = Cipher.getInstance(xform);
byte[] IV = { 11, 22, 33, 44, 55, 66, 77, 88, 99, 18, 69, 17, 72, 94, 18, 30 };
IvParameterSpec ips = new IvParameterSpec(IV);
cipher.init(Cipher.ENCRYPT_MODE, _key, ips);
String plainText = "abcdeffdkflsdkf";
byte[] cipherText = cipher.doFinal(plainText.getBytes());
I write this encrypted data in file and I want to decrypt this file in my java project where I am using following code:
SecretKeyFactory kf = SecretKeyFactory.getInstance("DES");
String key = "abcdefg";
DESKeySpec keySpec = new DESKeySpec(key.getBytes());
SecretKey _key = kf.generateSecret(keySpec);
String xform = "DES";
Cipher cipher = Cipher.getInstance(xform);
byte[] IV = { 11, 22, 33, 44, 55, 66, 77, 88, 99, 18, 69, 17, 72, 94, 18, 30 };
IvParameterSpec ips = new IvParameterSpec(IV);
cipher.init(Cipher.DECRYPT_MODE, _key, ips);
String cipherText;
//cipher text is read from file.
byte[] plainText = cipher.doFinal(cipherText.getBytes());
But it's not working.
When we do not specify mode of operation(i.e. CBC/ECB) and padding method(i.e. PKCS5Padding/NoPadding) and only algorithm name is specified for getting instance of Cipher then what are the default values which Android and Java use?
Does Android uses CBC by default? As it doesn't give error for IV. If I specify IV in init method and don't specify mode in my java project, it throws exception as IV cannot be used for ECB.
Thanks.

Both Android and Java default to "AES/ECB/PKCS5Padding". Both your key and IV are not of the correct size (so the code should not even run!) and you forget to perform (character) encoding/decoding correctly. Especially the ciphertext should never be directly converted into a string, as unprintable characters are likely to be dropped or converted.

How do I translate this C# encrypt function into Java?

I need to translate the below C# codes into Java, however, I could not find any Java equivalent to the Rfc2898DerivedBytes and Rijndael of C#.
private static string Encrypt(string sData, string sEncryptionKey)
{
string str = null;
string str2;
try
{
Rfc2898DeriveBytes bytes = new Rfc2898DeriveBytes(sEncryptionKey, 8);
Rijndael rijndael = Rijndael.Create();
rijndael.IV = bytes.GetBytes(rijndael.BlockSize / 8);
rijndael.Key = bytes.GetBytes(rijndael.KeySize / 8);
byte[] buffer = Encoding.Unicode.GetBytes(sData);
using (MemoryStream stream = new MemoryStream())
{
using (CryptoStream stream2 = new CryptoStream(stream, rijndael.CreateEncryptor(), CryptoStreamMode.Write))
{
stream.Write(bytes.Salt, 0, bytes.Salt.Length);
stream2.Write(buffer, 0, buffer.Length);
stream2.Close();
str = Convert.ToBase64String(stream.ToArray());
str2 = str;
}
}
}
catch (Exception exception)
{
System.out.println(exception.getMessage());
}
return str2;
}
[Update]
I need to use this function to encrypt the password for new created user, and the encrypted password should also be correctly decrypted by other invoker including C#.
I follow the documents which list in the comments and answer, and try to write below simply sample for quickly verification.
public class testEncrypt {
public static void main(String[] args) throws Exception {
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
char[] password = "passkey".toCharArray();
SecureRandom random = new SecureRandom();
byte[] salt = new byte[8];
random.nextBytes(salt);
KeySpec spec = new PBEKeySpec(password, salt, 1000, 256);
SecretKey tmp = factory.generateSecret(spec);
SecretKey secret = new SecretKeySpec(tmp.getEncoded(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, secret);
AlgorithmParameters params = cipher.getParameters();
byte[] iv = params.getParameterSpec(IvParameterSpec.class).getIV();
byte[] ciphertext = cipher.doFinal("301a7fed-54e4-4ae2-9b4d-6db057f75c91".getBytes("UTF-8"));
System.out.println(ciphertext.length);
}
}
However, the length of the ciphertext is 48, but actually in C#, it looks like this format
WHUNV5xrsfETEiCwcT0M731+Ak1jibsWEodJSaBraP1cmmkS1TpGWqwt/6p/a7oy8Yq30ImZPbFF+Y0JNLa3Eu2UGuazZtuhEepUIIdaDEtA2FO0JYIj2A==
total 120 characters.
Is there something wrong with the code?

RFC2898 is the official name for PBKDF2 (Password Based Key Derivation Function).
This question seems to use the SecretKeyFactory class for PBKDF2.
Password Verification with PBKDF2 in Java
If you cannot find any implementation that you are satisfied with, I suggest you take a look at my question where I used a few classes from BouncyCastle (for C#, but should work for Java) and created the algorithm. I had to create this for C# because there was no Rfc2898DeriveBytes for the .NET Compact Framework.
This question should definitely help you too!
You can also find an implementation here that was done by someone who stumbled across your same problem.
Also to answer the second part of your question,
Rijndael doesn't differ much from AES. To quote this webpage
Namely, Rijndael allows for both key and block sizes to be chosen
independently from the set of { 128, 160, 192, 224, 256 } bits. (And
the key size does not in fact have to match the block size). However,
FIPS-197 specifies that the block size must always be 128 bits in AES,
and that the key size may be either 128, 192, or 256 bits.
Rijndael algorithm was chosen by the NIST to be the Advanced Encryption algorithm.
So you can use the AES algorithm in Java.