Currently I have built an application for Android and PHP which encrypts some data using chacha20-poly1305. Those are working fine since I am using libsodium as their backbone.
Now I have created the same thing for an Arduino. However I am using a different library for that. I am using the following inputs:
Plaintext: 0000000000000001
Nonce: 0000000000000001
Key: b78b94bdf407e2fb0c4cb01e74fee7db743d4d5ab636fe4c181511137dedfc46
On libsodium it produces the following ciphertext with mac:
78260b2aca088071 3c8eea6f05b671ed72f1bc61fee7cc22
But on the Arduino:
78260b2aca088071 4d888c3b8fe1a4ab8a28d5e593fe7a25
So my question is: are both macs valid? They don't work vice versa, so what could the problem be of the Arduino variant?
There are two variants of ChaCha20-Poly1305, the original version and an IETF version. The IETF version takes a 12 byte nonce, while the original takes 8 bytes.
As as I understand it, the change in the IETF version is to make using random nonces more secure, as there is less chance reuse.
Your Android / PHP versions are using the legacy version, whilst your Arduino version is using the newer IETF version.
Libsodium implements both variants, (as well as a third, XChaCha20). The simplest solution therefore may be for you to change your existing code to use the IETF version. Alternatively you could change the Arduino version use the original variant, if that is possible with the library you are using.
Related
I've got a .Net Core appl and am using the System.Data.SQLite.dll package to connect to a SQLite DB.
I'm trying to encrypt the database with a password.
In version 1.0.93.0 of System.Data.SQLite.dll library I can set or change the password encryption of the database:
SQLiteConnection con = new SQLiteConnection($"Data Source=DBName;Version=3;");
conn.SetPassword($"{password}");
conn.ChangePassword($"{password}");
conn.Open();
In the latest version 1.0.113.7 the api's no longer to appear to be supported.
Visual Studio throws a compiler error on the SetPassword() and ChangePassword() calls.
How do I password encrypt my databases?
Is there another way to achieve this using this library (or something similar)?
Yes, it seems that starting with System.Data.SQLite version 1.0.113.0, support for encryption in this way was entirely removed in this checkin, by modifying the file /Targets/SQLite.NET.Settings.targets, and setting the value of InteropCodec to false.
Specifically the comment says "Merge all changes needed for the SQLite core library 3.32.0 release."
This reveals to us that the actual culprit is SQLite itself, where in release 3.32.0, they removed support for this type of encryption API as well, in this commit, where the comment says "simplify the code by removing the unsupported and undocumented SQLITE_HAS_CODEC compile-time option"
Neither the change in System.Data.SQLite nor in SQLite are documented in the release notes for these projects.
In prior versions of System.Data.SQLite, such as 1.0.112.1 and earlier, encryption via the SetPassword() method was supported, and this used the “SQLite Encryption Extension” (SEE)
I've been successfully using Vivado and the SDK to develop VHDL and C for the Zynq XC7Z010 on a Digilent Zybo board. I've also been using the GNAT GPS IDE to learn Ada targeted to an STM32F4 processor (using one of the supported development boards).
GPS also ships with a set of zynq7000 run-times targeted to the XC7Z020 (as far as I can tell). Having looked through the BSPs for these target I believe that the code generated should also run on the XC7Z010 as the ARM cores appear to be the same. It may turn out that there are differences, in which case I will have a go at building a specific run-time based on the existing zynq7000 BSP (Adacore have documented this process and give an example for generating a new STM32F4 BSP).
My main problem is I'm not sure how to load and run the generated Ada elf file on my Zybo. I have tried to generate a BOOT.ini file containing a FSBL (built with the SDK and using my exported hardware from Vivado), a bit-stream and the Ada elf file (The the Zybo has an MicroSD interface that can be configured as a boot device, this works perfectly with a bit-stream and C elf produced via Vivado / SDK).
Anyway, this didn't work... I'm guessing that it might be a linking issue, or a boot loader issue, or similar. With my current level of knowledge I'm just not sure at this stage.
Any advice or pointers would be greatly appreciated!
It turns out that my BOOT.ini was fine, the problem was related to accessing custom AXI registers defined in my bit-stream. If I remove these references from the Ada the generated ELF file works perfectly. For example, printing over the Zybo's VCP using Text_IO.Put_Line(), using Ada run-time delay and Clock operations etc.
For some reason the AXI interface isn't working when I boot an Ada ELF file. If I substitute this for the equivalent C, then all is well.
This particular problem is currently unresolved, but not related to my original question!
(It might be that the Ada run-time is relying on the FSBL or u-Boot to have initialised this, not sure. Feel free to comment if you know, I'll also add a comment when I resolve this)
**** Update ****
Here is some additional background and a description of what I had to do to get my custom AXI IPs to work.
The provided AdaCore BSP (Board Support Package used to build the run-time) is targeted at the Xilinx XC702 development board. I'm using a Digilent Zybo (the older version). The two boards use different Zynq parts, the XC702 is based on a XC7Z020 and the Zybo uses a XC7Z010 (there is a new version with a XC7Z020 option).
I followed the AdaCore instructions (available on their web site) and built a BSP specifically for the Zybo. Initially I just updated the clock details as the Zybo runs at a different speed and then verified that the Ada delay function worked correctly (provided as part of the Ravenscar run-time built from the updated BSP). However, my custom AXI IPs still didn't work...
To cut a long story short, the Ada run-time contains as assembly file called start-ram.S that amongst other things sets up the MMU. There is an include file called memmap.inc that contains the actual MMU page definitions as a series of .long directives. I had to update the AXI_GP0 address entry by editing the particular directive to,
.long 0x43c10c16 # for 0x43c00000, axi_gp0
Previously it was set to 0x00000000 # for 0x43c00000, *none*. These entries are decoded within start-ram.S and then used to configure the MMU (the top 12 bits set the page and the remaining bits are chopped up and used as page config).
So, once I edited this file in my Zybo BSP and re-built the run-time, the IPs became accessible from the PS and worked as expected. This all took a while to figure out, but was worth it as I learn loads whilst exploring the dead ends!
I hope this helps someone in the future, I also highly recommend Ada for Zynq development especially if you ultimately need DO-178 certification, or similar.
I'm knee deep in compilation for sqlite, system.data.sqlite, and xerial's JDBC trying to get an encrypted sqlite file working through all three. From my understanding, system.data.sqlite uses RC4 encryption, and SQLCipher/Rijndael/wxSqlite can use AES256.
Using this library, one can easily compile Windows binaries for AES256 encryption.
This library offers Xerial's JDBC by incorporating wxsqlite3's improvements, which it looks like is actually based on the above (Rijndael's) library.
Because the above two libraries are close to one-and-the-same, and use the same encryption, they have been compatible. I have a working Java project with the encryption-supporting JDBC, and I have a compiled sqlite3.dll and sqlite3shell.exe that allows me to use the command line to encrypt, read, write, etc databases. This sqlite dll and shell are compatible with the databases created with the JDBC.
Where I'm a bit lost is getting system.data.sqlite working with AES256. I need to use this library as it affords me the ability to use Entity Framework and LINQ. I had thought it would not be such an arduous task, but I've been ramming my head into a wall for the past few days on this issue. I have the encryption-ready sqlite3 dll, how do I merge this in with system.data.sqlite?
Thanks so much for any help.
If you're targeting .NET standard 4.6.1+ or Core, you may want to give Microsoft.Data.Sqlite a try. This can give you AES256 encryption by simply adding 2 Nuget Packages. By the way, there are paid options to get AES256 compiled System.Data.Sqlite. Some are listed in this answer.
If your project is currently using System.Data.Sqlite, then transitioning will involve some search/replace of method & class names, much of which is a difference in caps. For example, "SQLiteDataReader" becomes "SqliteDataReader."
Another difference is that Microsoft.Data.Sqlite is strict about column naming. For example, a command that references a column named "DateListed" will fail if the database schema has that column as "Datelisted."
If you want to explore making a transition install 2 nuget packages:
Install-Package Microsoft.Data.Sqlite.Core
Install-Package SQLitePCLRaw.bundle_sqlcipher
Setup SQLitePCL
SQLitePCL.raw.SetProvider(new SQLitePCL.SQLite3Provider_sqlcipher());
SQLitePCL.Batteries_V2.Init();
SQLitePCL.raw.FreezeProvider();
Create encrypted database
string error = string.Empty;
static SQLitePCL.sqlite3 sqlite
SQLitePCL.raw.sqlite3_open(dbPath, out sqlite);
SQLitePCL.raw.sqlite3_exec(sqlite, "PRAGMA key ='myPassword'", out error);
SQLitePCL.raw.sqlite3_close(sqlite);
I have to implement zero copy method in a program in Qt C++,I read about it and got transferto() method.as described below:
public void transferTo(long position, long count, WritableByteChannel target);
but i can't understand how it works.It is written that Internally, it depends on the underlying operating system's support for zero copy.
So I tried to write a function but i didn't get the meaning of "position" and "channel" here.
Can anyone help me?
There is no cross-platform way to do zero copy in C++, and there is no zero-copy API in Qt. You can implement it for your target OS using provided API:
Linux supports zero copy through system calls such as sys/socket.h's
sendfile, sendfile64, and splice. Windows supports zero copy through
the TransmitFile API.
Source
I know a bit about JDK and JRE source and binary compatibility (e.g. this and this), but not sure about the following situation:
Consider I have an application which is compiled using JDK5 and runs on JRE6. It uses some libraries (jars) which are also compiled using JDK5.
Now I want to compile my application using JDK6. What new problems could arise in runtime in such a case (particularly, in compatibility with the "old" jars)? Should I fully retest the application (touch every library) or can rely on promised JDK/JRE compatibility?
Normally no problems should arise if you set the compiler option of JDK6 to use 1.5 source compatibility. However sometimes this is not always true.
I remember once when compiling 1.4 code with 1.5 compiler (using 1.4 compatibility). The jars where ok (1.4 binary level) but the application crashed due to a funny conversion.
We used a BigDecimal number passing an integer as argument to the constructor. The 1.4 version had only a constructor from double but the 1.5 version had both, the int and the double constructors. So when compiling with 1.4 compiler made the automatic conversion from int to double, but with the 1.5 compiler it checked that the int constructor existed and did not realize that conversion. Then when using the perfect binary compatible code on 1.4 JRE the program crashed with a NoSuchMethodException.
I have to admit that it was a strange case, but it is one of those cases where logic does not work. So my advice is if you plan to compile for older versions of JRE try to use the target version JDK whenever possible.
Untill and unless you have not changed your code and added new Java 6 features, there should be no issues.
With regards to other jars there should be no issues at all.
JDK always maintains backward compatibility.
Compatibility mostly works. I would not expect any issue for you to arise aside from various warnings for e.g. not using generics. Maybe some barely used APIs were deprecated, but I assume they were left in place, just marked as deprecated.
Just try it, if it compiles you should be fine.
A key design aspect of Java - unfortunately - is full backwards compatibility.
There are very few exceptions where backwards compatibility was not preserved; most prominently Eclipse suffered when the sorting algorithm was changed from a stable to a non-stable sort algorithm (the order of objects that sort identically was no longer preserved); but that was never part of the Java specification, but a bug in Eclipse.
It's unfortunate, because there were a few poor choices that now cannot be changed. Iterator should not have had a remove() function in the API, Vector should not have been synchronized (solved by having ArrayList now), StringBuffer should not have been synchronized, hence StringBuilder. String should probably have been an interface, not a class, to allow for e.g. 8-bit strings, 32-bit strings - CharSequence is the better string interface, but too many methods do not accept CharSequence and require returning a String. Observable should be an interface too: you cannot make a subclass observable with this API. To name a few. But because of backwards compatibility, these cannot be fixed anymore until maybe JDK modularization (at which point some can at least disappear into an donotuse module ...).
Of course you should already have thousands of unit tests to help you test with the new JDK... :-)