Related
I'm using PN532 and Arduino Uno
I'm uploading this code to change the sector trailer for sector 4 in block 19
memcpy(data, (const uint8_t[]){ 0x45, 0x48, 0x61, 0x21, 0x26, 0x39, 0x0f, 0x00, 0xff, 0, 0x50, 0x67, 0x39, 0x78, 0x5e, 0x33 }, sizeof data);
success = nfc.mifareclassic_WriteDataBlock (19, data);
then im want to read blocks 16 and 18 with KeyB this is the auth code
uint8_t keyb[6] = { 0x50, 0x67, 0x39, 0x78, 0x5E, 0x33 };
success = nfc.mifareclassic_AuthenticateBlock(uid, uidLength, 19, 0, keyb);
are my access bits wrong or to use keyb to auth is use a different code
I need some help with CRC calculation. I spent a week trying to understand how a CRC (or Checksum) is calculated on a communication protocol
I have a Endress+Hauser pH probe (CPS11D-7FA21) that has MemoSense connector. Basically it is a digital pH probe. The communication is RS485 but the protocol is proprietary, so no info on that.
I connected the probe to a meter and sniffed the frames. There is a lot of data going back and fourth in the beginning but the polling repeats.
I was able to write some code for an Arduino and it worked, I can initialize the probe and pool measurements (ph(mV) and temperature), but the problem is that it only work with one probe. If I connect a new one it all stops.
I was digging a bit and I found out that right before the pooling starts the Init frame is different... Ii seem the measuring device somehow calculates the Init data from some other data that is exchanged in the beginning.
Anyway the fist thing is that I want to understand how the data frame is constructed.
Here is an example of pooling one of the probes and the data changes slightly
0x01, 0x01, 0x00, 0x00, 0x00, 0x2e, 0x04, 0x03, 0x09, 0x00, 0x20, 0xb9
0x01, 0x01, 0x00, 0x00, 0x00, 0x2f, 0x04, 0x03, 0x09, 0x00, 0x21, 0x99
0x01, 0x01, 0x00, 0x00, 0x00, 0x30, 0x04, 0x03, 0x09, 0x00, 0x3e, 0x7a
0x01, 0x01, 0x00, 0x00, 0x00, 0x32, 0x04, 0x03, 0x09, 0x00, 0x3c, 0x3a
0x01, 0x01, 0x00, 0x00, 0x00, 0x33, 0x04, 0x03, 0x09, 0x00, 0x3d, 0x1a
| <-------------------> | \ / \ / | | |
Header pH(mV)/10 Temp/100 ? Csum CRC???
0x01, 0x01, 0x00, 0x00, 0x00, 0x8d, 0x06, 0xf4, 0x08, 0x00, 0x77, 0x56
0x01, 0x01, 0x00, 0x00, 0x00, 0x8f, 0x06, 0xf4, 0x08, 0x00, 0x75, 0x16
0x01, 0x01, 0x00, 0x00, 0x00, 0x88, 0x06, 0xf4, 0x08, 0x00, 0x72, 0xf6
0x01, 0x01, 0x00, 0x00, 0x00, 0x94, 0x06, 0xf5, 0x08, 0x00, 0x6f, 0x7d
0x01, 0x09, 0x04, 0x00, 0x0c, 0x00, 0x14, 0x02, 0x03, 0x11, 0x36, 0x66, 0x61, 0x63, 0x74, 0x6f, 0x72, 0x79, 0x20, 0x20, 0x20, 0x20, 0x46, 0x57
0x01, 0x09, 0x04, 0x00, 0x0c, 0x00, 0x15, 0x07, 0x17, 0x12, 0x26, 0x66, 0x61, 0x63, 0x74, 0x6f, 0x72, 0x79, 0x20, 0x20, 0x20, 0x20, 0x45, 0xb0
0x01, 0x00, 0x04, 0x00, 0x05, 0xa8, 0x4b, 0x53, 0x47, 0x31, 0x20, 0x01, 0x01, 0x01, 0x5a, 0x02, 0x9f, 0x27, 0x40, 0x39, 0x3f, 0x04, 0x52, 0x31, 0x32, 0x38, 0x44, 0x46, 0x30, 0x35, 0x42, 0x30, 0x33, 0x14, 0x01, 0x16, 0x00, 0x69, 0x00
0x01, 0x00, 0x04, 0x00, 0x05, 0xa8, 0x4b, 0x53, 0x47, 0x31, 0x20, 0x01, 0x01, 0x01, 0x01, 0x00, 0x75, 0x27, 0x41, 0xb8, 0x41, 0x04, 0x53, 0x36, 0x33, 0x37, 0x45, 0x44, 0x30, 0x35, 0x42, 0x30, 0x37, 0x15, 0x07, 0x06, 0x00, 0x3c, 0xf3
0x01, 0x08, 0x04, 0x00, 0x0d, 0xb0, 0xe5, 0x69, 0x1b, 0x00, 0x00, 0x69, 0x1b, 0x15, 0x07, 0x17, 0x12, 0x26, 0x02, 0x44, 0x1b, 0xaa, 0x0f, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x66, 0x61, 0x63, 0x74, 0x6f, 0x72, 0x79, 0x20, 0x20, 0x20, 0x20, 0xe9, 0xcd
0x01, 0x08, 0x04, 0x00, 0x0d, 0x40, 0xe7, 0x58, 0x1b, 0x00, 0x00, 0x67, 0x1b, 0x14, 0x02, 0x03, 0x11, 0x36, 0x02, 0x44, 0x1b, 0xaa, 0x0f, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x66, 0x61, 0x63, 0x74, 0x6f, 0x72, 0x79, 0x20, 0x20, 0x20, 0x20, 0x27, 0xde
Here is what I learned so far, the Csum is a standard 8bit Xor checksum
that works here
https://www.scadacore.com/tools/programming-calculators/online-checksum-calculator/
But the CRC is a mystery for me ... I tried multiple calculator and different data pieces and nothing. To me it seems it is a CRC because the if one bit changes there is a huge difference in the CRC byte
Maybe someone here could shed some light on this
Thank you
The last byte appears to be an exclusive-or and rotate check on the non-header bytes. If the message with check values is the unsigned char array a[0..len-1], then this computes the last two check values, x == a[len - 2] and y == a[len - 1]:
unsigned x = 0, y = 0;
for (size_t i = 0; i < len - 2; i++)
x ^= a[i];
for (size_t i = 5; i < len - 2; i++) {
y = (y ^ a[i]) << 1;
if (y & 0x100)
y ^= 0x101;
}
I'm playing around with DES encryption using CBC mode, and I came across something puzzling. I have a payload (not generated by me, but for which I know the key), accompanied by an IV, as well as a salt, which is meant to be XOR'd with the IV. On my first attempt to decrypt this payload, I found that bytes 3-7 of the plaintext were garbage, but the rest of the plaintext appeared correct. Eventually I discovered that I had failed to mix in the salt. The first 3 bytes of the salt happened to be 0, which explained why the first 3 bytes of the plaintext matched what I expected, but what I can't understand is why the incorrect IV had no impact on bytes 8 through the end of the payload. I found that I could set both the IV and the salt to any value (including all zeros), and still, only the first block (8 bytes) was impacted.
Seeing as this is all highly non-sensitive stuff (i.e. me fiddling around with SNMPv3 on a very out-dated Cisco switch on my local network with a one-word lowercase password, not to mention it doesn't even support AES), I feel no qualms sharing the following with you:
#include <stdio.h>
#include <openssl/des.h>
int main()
{
DES_key_schedule key;
DES_cblock privKey = { 0xc8, 0x13, 0x1b, 0xf0, 0x41, 0xf8, 0xae, 0xef };
DES_cblock iv = { 0xb5, 0xed, 0x65, 0x57, 0x7c, 0x99, 0x54, 0xe4 };
DES_cblock salt = { 0x00, 0x00, 0x00, 0x10, 0x63, 0xc6, 0x01, 0x82 };
const uint8_t cipher[] = {
0xc7, 0xf5, 0x53, 0xe5, 0xb3, 0x8a, 0x19, 0x8b,
0x03, 0xde, 0x49, 0xbb, 0x47, 0x38, 0x73, 0xb7,
0x96, 0x24, 0xa3, 0xba, 0x3a, 0x28, 0x79, 0x16,
0x8b, 0xe4, 0xbf, 0xb6, 0xfc, 0xc2, 0x86, 0xc7,
0x8f, 0x1e, 0x0c, 0x87, 0x53, 0xbe, 0xfc, 0x0a,
0xcd, 0x6a, 0x1a, 0xb3, 0xaa, 0x44, 0xcc, 0xb1,
0xc0, 0x5e, 0xe0, 0x98, 0x33, 0x26, 0x4b, 0xc4,
0x73, 0xa2, 0x93, 0x72, 0x86, 0x5e, 0xd0, 0xdf,
0x4f, 0x7f, 0x53, 0x92, 0xb5, 0xd6, 0x54, 0x16,
0x18, 0x55, 0xe6, 0xc7, 0xb0, 0x6f, 0x6b, 0xa7,
0x53, 0x13, 0x4a, 0x66, 0xc8, 0x65, 0xbf, 0x18,
0x2d, 0x00, 0x1c, 0xe5, 0x2e, 0xbc, 0xb2, 0x7f,
0x76, 0x03, 0x46, 0xaf, 0xac, 0xf7, 0xb3, 0x47,
0xbe, 0x09, 0xcc, 0x78, 0x9b, 0xf7, 0xae, 0x8f,
0x1f, 0xb7, 0xbb, 0xe6, 0x4f, 0x3a, 0xad, 0xdc,
0x5d, 0xde, 0xb4, 0x68, 0x4d, 0x5a, 0x68, 0x59,
0xa3, 0xc5, 0x33, 0x88, 0xad, 0x67, 0xa7, 0x2c,
0x7a, 0xe0, 0x45, 0x37, 0x41, 0x2d, 0x5d, 0xeb,
0x59, 0x20, 0xd1, 0x3e, 0x5f, 0x8b, 0x12, 0xb0,
0xcd, 0x1d, 0xd5, 0xf0, 0x1a, 0xe7, 0x64, 0x41,
0x37, 0xc1, 0xd1, 0x0c, 0x23, 0xc9, 0x90, 0x32,
0xf8, 0x21, 0xb9, 0xd6, 0x0e, 0x0e, 0x78, 0x2d,
0xf0, 0x79, 0x8c, 0x2c, 0x44, 0x04, 0x10, 0x48,
0xd7, 0xdb, 0x4c, 0xe5, 0xeb, 0x40, 0xb4, 0x4a,
0xa9, 0xb5, 0xf7, 0xa6, 0xce, 0x06, 0x28, 0xf4,
0xac, 0x99, 0xf8, 0x01, 0x88, 0xde, 0xb8, 0x75,
0x11, 0xb6, 0x2c, 0x87, 0x22, 0x8e, 0xfe, 0x3e,
0x0b, 0x7b, 0x15, 0xaa, 0xed, 0x1d, 0xaf, 0xfa,
0x88, 0x96, 0xd2, 0x8f, 0x57, 0xf8, 0xcd, 0xf6,
0x14, 0x7c, 0xbf, 0x69, 0x3d, 0x3e, 0x61, 0x2c,
0xb8, 0x01, 0x5a, 0x8a, 0x6a, 0xb1, 0x58, 0x0f,
0xa7, 0xd7, 0xc7, 0x5b, 0xe0, 0x0b, 0x3f, 0x05,
0x88, 0x85, 0xbb, 0xea, 0x82, 0x3e, 0x6f, 0xf4,
0xb7, 0x52, 0x4c, 0xc4, 0xea, 0x51, 0xfd, 0xb6,
0xc4, 0x5b, 0x65, 0x2e, 0xac, 0x29, 0x3c, 0x19,
0x40, 0x08, 0x5d, 0xa7, 0xad, 0xa8, 0x8c, 0x61,
0x78, 0xaa, 0xc4, 0xa2, 0x38, 0x72, 0x45, 0x84,
0x3d, 0x94, 0x8c, 0xa3, 0xba, 0x88, 0xf4, 0x79,
0x0a, 0x87, 0xc6, 0xe9, 0xd3, 0x0e, 0xd0, 0xd0
};
uint8_t plain[sizeof(cipher)];
int i;
for (i = 0; i < sizeof(DES_cblock); i++) {
iv[i] ^= salt[i];
}
DES_set_odd_parity(&privKey);
DES_set_key_unchecked(&privKey, &key);
DES_ncbc_encrypt(cipher, plain, sizeof(cipher), &key, &iv, DES_DECRYPT);
for (i = 0; i < sizeof(plain); i++) {
if (i) {
putchar(i % 8 ? ' ' : '\n');
}
printf("0x%02x", plain[i]);
}
putchar('\n');
}
To compile:
gcc -o main main.c -lcrypto
Running ./main produces the following output:
0x30 0x82 0x01 0x34 0x04 0x0c 0x80 0x00
0x00 0x09 0x03 0x00 0x00 0x24 0x13 0x70
0xb2 0xc1 0x04 0x00 0xa2 0x82 0x01 0x20
0x02 0x04 0x75 0xd7 0x16 0x29 0x02 0x01
0x00 0x02 0x01 0x00 0x30 0x82 0x01 0x10
0x30 0x82 0x01 0x0c 0x06 0x08 0x2b 0x06
0x01 0x02 0x01 0x01 0x01 0x00 0x04 0x81
0xff 0x43 0x69 0x73 0x63 0x6f 0x20 0x49
0x6e 0x74 0x65 0x72 0x6e 0x65 0x74 0x77
0x6f 0x72 0x6b 0x20 0x4f 0x70 0x65 0x72
0x61 0x74 0x69 0x6e 0x67 0x20 0x53 0x79
0x73 0x74 0x65 0x6d 0x20 0x53 0x6f 0x66
0x74 0x77 0x61 0x72 0x65 0x20 0x0d 0x0a
0x49 0x4f 0x53 0x20 0x28 0x74 0x6d 0x29
0x20 0x43 0x32 0x39 0x34 0x30 0x20 0x53
0x6f 0x66 0x74 0x77 0x61 0x72 0x65 0x20
0x28 0x43 0x32 0x39 0x34 0x30 0x2d 0x49
0x36 0x4b 0x32 0x4c 0x32 0x51 0x34 0x2d
0x4d 0x29 0x2c 0x20 0x56 0x65 0x72 0x73
0x69 0x6f 0x6e 0x20 0x31 0x32 0x2e 0x31
0x28 0x32 0x32 0x29 0x45 0x41 0x31 0x33
0x2c 0x20 0x52 0x45 0x4c 0x45 0x41 0x53
0x45 0x20 0x53 0x4f 0x46 0x54 0x57 0x41
0x52 0x45 0x20 0x28 0x66 0x63 0x32 0x29
0x0d 0x0a 0x54 0x65 0x63 0x68 0x6e 0x69
0x63 0x61 0x6c 0x20 0x53 0x75 0x70 0x70
0x6f 0x72 0x74 0x3a 0x20 0x68 0x74 0x74
0x70 0x3a 0x2f 0x2f 0x77 0x77 0x77 0x2e
0x63 0x69 0x73 0x63 0x6f 0x2e 0x63 0x6f
0x6d 0x2f 0x74 0x65 0x63 0x68 0x73 0x75
0x70 0x70 0x6f 0x72 0x74 0x0d 0x0a 0x43
0x6f 0x70 0x79 0x72 0x69 0x67 0x68 0x74
0x20 0x28 0x63 0x29 0x20 0x31 0x39 0x38
0x36 0x2d 0x32 0x30 0x30 0x39 0x20 0x62
0x79 0x20 0x63 0x69 0x73 0x63 0x6f 0x20
0x53 0x79 0x73 0x74 0x65 0x6d 0x73 0x2c
0x20 0x49 0x6e 0x63 0x2e 0x0d 0x0a 0x43
0x6f 0x6d 0x70 0x69 0x6c 0x65 0x64 0x20
0x46 0x72 0x69 0x20 0x32 0x37 0x2d 0x46
If I instead fill iv and salt with all zeros, the first line changes to the following, while the rest remains the same:
0x85 0x6f 0x64 0x73 0x1b 0x53 0xd5 0x66
So the obvious question is, what is going on here?
If anyone can answer that, I would also ask
Has this behavior been observed/documented anywhere?
Why use CBC with DES at all if it provides so little benefit (well, yeah, I know no one really encourages using DES anymore)?
The answer is perfectly simple, and has nothing to do with DES, and everything to do with CBC mode. Thank you to #Topaco for pointing it out to me.
The IV does propagate changes to all blocks when performing encryption, and has the effect of randomizing the contents of each block. Two identical plaintext blocks will produce wildly different ciphertext, so it limits the amount of information that is leaked directly through the ciphertext.
On the other hand, CBC allows you to decrypt any block without first decrypting the blocks before it. This allows decryption to be parallelized. However, it causes exactly the behavior presented in the question. The IV is not required to decrypt any block except the first one.
I'm looking into using curve25519 on a javacard 3.0.4 but I got stuck and I have the following questions:
Does javacard 3.0.4 support such a curve?
What I've tried so far was to convert the Montgomery equation to a Weierstrass equation. Doing this and using Bernstein's website I got the following parameters:
p = 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffed
a = 0x2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa984914a144
b = 0x7b425ed097b425ed097b425ed097b425ed097b425ed097b4260b5e9c7710c864
r = 0x1000000000000000000000000000000014def9dea2f79cd65812631a5cf5d3ed
Gx = 0x9
Gy = 0x20ae19a1b8a086b4e01edd2c7748d14c923d4d7e6d7c61b229e9c5a27eced3d9
As I found some other values on the internet I also tried with
Gx: 0x2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaad245a
Then I followed the implementation from ykneo-curves and ended up with this:
public class Curve25519 {
public final static byte[] p = { // 32 bytes
(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff,
(byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff,
(byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff,
(byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xff, (byte) 0xed };
public final static byte[] a = { // 32 bytes
(byte) 0x2a, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa,
(byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa,
(byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0xaa,
(byte) 0xaa, (byte) 0xaa, (byte) 0xaa, (byte) 0x98, (byte) 0x49, (byte) 0x14, (byte) 0xa1, (byte) 0x44 };
public final static byte[] b = { // 32 bytes
(byte) 0x7b, (byte) 0x42, (byte) 0x5e, (byte) 0xd0, (byte) 0x97, (byte) 0xb4, (byte) 0x25, (byte) 0xed,
(byte) 0x09, (byte) 0x7b, (byte) 0x42, (byte) 0x5e, (byte) 0xd0, (byte) 0x97, (byte) 0xb4, (byte) 0x25,
(byte) 0xed, (byte) 0x09, (byte) 0x7b, (byte) 0x42, (byte) 0x5e, (byte) 0xd0, (byte) 0x97, (byte) 0xb4,
(byte) 0x26, (byte) 0x0b, (byte) 0x5e, (byte) 0x9c, (byte) 0x77, (byte) 0x10, (byte) 0xc8, (byte) 0x64 };
public final static byte[] G = { // 65 bytes
(byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00,
(byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00,
(byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00,
(byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00,
(byte) 0x09, (byte) 0x20, (byte) 0xae, (byte) 0x19, (byte) 0xa1, (byte) 0xb8, (byte) 0xa0, (byte) 0x86,
(byte) 0xb4, (byte) 0xe0, (byte) 0x1e, (byte) 0xdd, (byte) 0x2c, (byte) 0x77, (byte) 0x48, (byte) 0xd1,
(byte) 0x4c, (byte) 0x92, (byte) 0x3d, (byte) 0x4d, (byte) 0x7e, (byte) 0x6d, (byte) 0x7c, (byte) 0x61,
(byte) 0xb2, (byte) 0x29, (byte) 0xe9, (byte) 0xc5, (byte) 0xa2, (byte) 0x7e, (byte) 0xce, (byte) 0xd3,
(byte) 0xd9 };
public final static byte[] r = { // 32 bytes
(byte) 0x10, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00,
(byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00,
(byte) 0x14, (byte) 0xde, (byte) 0xf9, (byte) 0xde, (byte) 0xa2, (byte) 0xf7, (byte) 0x9c, (byte) 0xd6,
(byte) 0x58, (byte) 0x12, (byte) 0x63, (byte) 0x1a, (byte) 0x5c, (byte) 0xf5, (byte) 0xd3, (byte) 0xed };
static public KeyPair newKeyPair() {
KeyPair kp = new KeyPair(KeyPair.ALG_EC_FP, (short) 256);
ECPrivateKey ecPrv = (ECPrivateKey) kp.getPrivate();
ECPublicKey ecPub = (ECPublicKey) kp.getPublic();
ecPrv.setFieldFP(p, (short) 0, (short) p.length);
ecPrv.setA(a, (short) 0, (short) a.length);
ecPrv.setB(b, (short) 0, (short) b.length);
ecPrv.setG(G, (short) 0, (short) G.length);
ecPrv.setR(r, (short) 0, (short) r.length);
ecPub.setFieldFP(p, (short) 0, (short) p.length);
ecPub.setA(a, (short) 0, (short) a.length);
ecPub.setB(b, (short) 0, (short) b.length);
ecPub.setG(G, (short) 0, (short) G.length);
ecPub.setR(r, (short) 0, (short) r.length);
return kp;
}
}
In the applet I have the following code:
private MyApplet(byte[] bArray, short bOffset, byte bLength) {
ecKeyPair = Curve25519.newKeyPair();
ecKeyPair.genKeyPair();
register();
}
public static void install(byte[] bArray, short bOffset, byte bLength) {
new MyApplet(bArray, bOffset, bLength);
}
When I try to install it on the javacard using GPP I get the following exception:
pro.javacard.gp.GPException: Install for Install and make selectable failed SW: 6F00
at pro.javacard.gp.GlobalPlatform.check(GlobalPlatform.java:1092)
at pro.javacard.gp.GlobalPlatform.installAndMakeSelectable(GlobalPlatform.java:798
)
at pro.javacard.gp.GPTool.main(GPTool.java:478)
Can I use Curve25519 keypairs for ECDSA javacard signing?
Not quite. Montgomery and Weierstrass forms can be converted into each other: http://samuelkerr.com/?p=431
However, there are various caveats getting this to work on Javacards, and part of the curve operations / conversion has to be done on a PC talking to the card. I'm currently working on this and am happy to share the code once it's actually done.
UPDATE: I uploaded the respective code here: https://github.com/david-oswald/jc_curve25519
No, such curves are not directly supported.
All Java Card Elliptic Curve facilities use the Weierstraß equation which is
y^2 = x^3 + a*x + b mod p
Curve 25519 is based on
y^2 = x^3 + 486662*x^2 + x mod p
Unfortunately its not possible to directly support such Montgomery curves.
Is it possible to add an binary data file together with a Arduino sketch that is transferred when sending it over to the Arduino? I manage to add the file in the IDE and it was copied to a "data" directory in my project folder but I can't find a way to access it in my code.
I'm just interested to send one file for testing purposes and don't want to use SD cards or network. I'm using the Arduino-Uno.
You can convert the binary data to a C array, and insert that into the code/source which will allow you to reference it.
A tool like Hexworkshop or other binary file editor should have an option to do this for you.
You could check this answer as well.
Example output:
unsigned char data[84] = {
0x02, 0x00, 0x41, 0x8E, 0x08, 0x8F, 0x09, 0x85, 0x09, 0x82, 0x85, 0x08, 0x83, 0xE0, 0xFE, 0xA3,
0xE0, 0x8E, 0x0A, 0xF5, 0x0B, 0x4E, 0x70, 0xEF, 0x85, 0x09, 0x82, 0x85, 0x08, 0x83, 0xE0, 0xFE,
0xA3, 0xE0, 0xFF, 0x7C, 0x00, 0x7D, 0x00, 0x02, 0x00, 0x00, 0x7B, 0x00, 0x7A, 0x00, 0x79, 0x01,
0x80, 0x06, 0x7B, 0x00, 0x7A, 0x00, 0x79, 0x00, 0x8A, 0x0A, 0x89, 0x0B, 0xE9, 0x4A, 0x70, 0xD8,
0x22, 0x78, 0x7F, 0xE4, 0xF6, 0xD8, 0xFD, 0x75, 0x81, 0x0B, 0x02, 0x00, 0x4D, 0x7F, 0x00, 0x7E,
0x80, 0x02, 0x00, 0x03,
} ;