Develop Reference

Camel SFTP component - SSH private key URI works with privateKeyFile, doesn't work with privateKey

I have a camel route that looks like the next one:
from("direct:download")
.pollEnrich()
.simple("sftp://my.host:22/folder/?username=foo&fileName=${header.CamelFileName}
&privateKeyFile=src/main/resources/privateSSHKey")
.to("file://state/downloaded");
The file src/main/resources/privateSSHKey is an RSA private key. That works without a problem : JSCH (library used by Camel for the SFTP endpoint) manages to connect and download the desired file.
The previous setup is ok while developing, because I can have the file with the key locally.
However, for prod, we have other system in which I will be able to get a byte array with the content of the key. For that, I am changing the route to look like this:
from("direct:download")
.pollEnrich()
.simple("sftp://my.host:22/folder/?username=foo&fileName=${header.CamelFileName}
&privateKey=" + URLEncoder.encode(new String(sshPrivateKey), "UTF-8"))
.to("file://state/downloaded");
...being sshPrivateKey the byte array. Unfortunately, I always get "auth_cancel" from JSCH, and debugging I can see that this happens when trying to handshake with the SFTP server.
Am I missing something? I am pretty sure that encoding the sshPrivateKey byte[] is the way to go (JSCH was complaining about wrong key if I didn't do it), but I am not sure about what else I am missing?

The origin of the problem is the encoding, the URLEncoding, byte and String can loose some character like + or \\.
I managed to make it work with Byte[] parameter for privateKey method Java DSL.
Example:
String privateKeyString = Files.readString(Path.of("/.ssh/private_key_rsa"), StandardCharsets.UTF_8);
getCamelContext().getRegistry().bind("myPrivateKey", privateKeyString.toByteArray())
from("file://tmp")
.to(sftp("localhost")
.username("test")
.privateKey("#myPrivateKey"));

C# - double-Value transmitted to Java client via byte[]

I am transmitting a double value from a C#-mqtt client to a Java-mqtt client. Mqtt requires its payload to be a byte[] so I in c# I am doing the following:
byte[] vals = BitConverter.GetBytes(sub.value); // c#-sender
and transmitting this over mqtt to a java client, which in turn
double result = ByteBuffer.wrap(vals).getDouble(); // java-receiver
However, while the original double-value is in the range of ~1 to 10, the resulting java value is in the range of 10^-311 to 10^-312.
I am not very familiar with c# at this point and can't find the problem.
Is it an offset problem? LE/BE ? I am pretty much stuck and would love if you could give me a hint.

As mentioned in the comments, try flipping the byte order on the ByteBuffer using the ByteBuffer.order(ByteOrder) method

Charset bug in AES Decryption on Android system

Good evening!
In my android app the smartphones load a AES encrypted String from my server and store it in a variable. After that process the variable and a key are pass to a method which decrypt the string. My mistake is that german umlauts (ä, ü, ö) aren't correct decoded. All umlauts displayed as question marks with black background...
My Code:
public static String decrypt(String input, String key) {
byte[] output = null;
String newString = "";
try {
SecretKeySpec skey = new SecretKeySpec(key.getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
cipher.init(Cipher.DECRYPT_MODE, skey);
output = cipher.doFinal(Base64.decode(input, Base64.DEFAULT));
newString = new String(output);
} catch(Exception e) {}
return newString;
}
The code works perfectly - only umlauts displayed not correctly, an example is that (should be "ö-ä-ü"):
How can I set the encoding of the decrypted String? In my iOS app I use ASCII to encoding the decoded downloaded String. That works perfectly! Android and iOS get the String from the same Server on the same way - so I think the problem is the local Code above.
I hope you can help me with my problem... Thanks!

There is no text but encoded text.
It seems like you are guessing at the character set and encoding—That's no way to communicate.
To recover the text, you need to reverse the original process applied to it with the parameters associated with each step.
For explanation, assume that the server is taking text from a Java String and sending it to you securely.
String uses the Unicode character set (specifically, Unicode's UTF-16 encoding).
Get the bytes for the String, using some specific encoding, say ISO8859-1. (UTF-8 could be better because it is also an encoding for the Unicode character set, whereas ISO8859-1 has a lot fewer characters.) As #Andy points out, exceptions are your friends here.
Encrypt the bytes with a specific key. The key is a sequence of bytes, so, if you are generating this from a string, you have to use a specific encoding.
Encode the encrypted bytes with Base64, producing a Java String (again, UTF-16) with a subset of characters so reduced that it can be re-encoded in just about any character encoding and placed in just about any context such as SMTP, XML, or HTML without being misinterpreted or making it invalid.
Transmit the string using a specific encoding. An HTTP header and/or HTML charset value is usually used to communicate which encoding.
To receive the text, you have to get:
the bytes,
the encoding from step 5,
the key from step 3,
the encoding from step 3 and
the encoding from step 2.
Then you can reverse all of the steps. Per your comments, you discovered you weren't using the encoding from step 2. You also need to use the encoding from step 3.

Writing data to serial port, sends wrong character

When monitoring data sent to device i get this:
http://i.stack.imgur.com/u0kIT.png
but i expect one character: F0 ð
public void WritingDataToPort() {
SerialPort port = new SerialPort("COM26");
try {
System.out.println(port.openPort());
port.setParams(9600, 8, 1, 0);
port.writeString((char)240+""));
port.closePort();
} catch (SerialPortException ex) {
System.out.println(ex);
}
}
I completly don't know how to send this "ð" characater. Tried all ascii codes.

You can't just send the char (or UTF8) through the serial port. You have to convert it.
First get the length of the char in UTF-8, then get the bytes and send the bytes.
Getting the size of UTF-8: Getting the actual length of a UTF-8 encoded std::string?
Then send it one by one. On the other side you need something to assemble them back.
You could also consider using a better alternative to writing bytes directly to the port, such as http://code.google.com/p/java-simple-serial-connector/

You could try unicode. UTF-8 code.
http://www.fileformat.info/info/unicode/char/f0/index.htm
C/C++/Java source code "\u00F0"

NSData bytes not matching bytes from Java WS with same base64 string

I am using protocol buffers in an iOS application. The app consumes a web service written in Java, which spits back a base64 encoded string.
The base64 string is the same on both ends.
In the app however, whenever I try to convert the string to NSData, the number of bytes may or may not be the same on both ends. The result is a possible invalid protocol buffer exception, invalid end tag.
For example:
Source(bytes) | NSData | Diff
93 93 0
6739 6735 -4
5745 5739 -6
The bytes are equal in the trivial case of an empty protocol buffer.
Here is the Java source:
import org.apache.commons.codec.binary.Base64;
....
public static String bytesToBase64(byte[] bytes) {
return Base64.encodeBase64String(bytes);
}
On the iOS side, I have tried various algorithms from similar questions which all agree in byte size and content.
What could be causing this?

On closer inspection, the issue was my assumption that Base64 is Base64. I was using the url variant in the web service while the app's decode was expecting a normal version.
I noticed underscores in the Base64, which I thought odd.
The Base64 page http://en.wikipedia.org/wiki/Base64 map of value/char shows no underscores, but later in the article goes over variants, which do use underscores.