StrokesPlus.net
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
Settings file encryption details - Details about how the settings file is encrypted
Options
Go to last post Go to first unread
Previous Topic Next Topic
randomConstant  
#1 Posted : Wednesday, January 26, 2022 12:11:55 PM(UTC)
randomConstant

Rank: Advanced Member

Reputation:

Groups: Translators, Approved
Joined: 7/17/2021(UTC)
Posts: 135

Thanks: 35 times
Was thanked: 18 time(s) in 15 post(s)
Hi Rob

I was wondering if you could please share how the settings file is encrypted for S+ and which encryption algorithm is used to achieve that.

I'm no security expert but got a bit worried about S+ encryption since I am using this wonderful software for many private things, including auto mounting VeraCrypt containers, and the settings file contains passwords and other important data. I would like to avoid having S+ as the weakest link if possible.

I searched on forum and site but couldn't find any mentions, maybe this is the first discussion about it.

Thanks
Back to top

Wanna join the discussion?! Login to your StrokesPlus.net Forum forum account, or Register a new forum account.
Back to top  
Rob  
#2 Posted : Wednesday, January 26, 2022 3:01:52 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,359
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 419 time(s) in 356 post(s)
Below is the source code of the encrypt method.

Note that SALT is an internal value and password is conditional based on the intended action.

For the local file encryption, it uses the password you've defined - that password isn't transmitted to the S+ servers. While I'm also not a security expert, this is a quite secure method as it's using solid encryption methods and the password you have defined.

For synchronizing settings with the S+ server, your file is encrypted using the SALT and your forum username as the password - I made this decision to keep it simple for people to pull down a previous settings upload where they may no longer remember the password. They have to know the current forum username and password to be able to download the settings, but if they had access to be able to login to the forum - it wouldn't really matter since they could just export the settings to a file which is not encrypted.

For the highest security, I would recommend not logging in from the S+ tray icon, only set the local password. Since the encrypted file sent to the server is only SALT + username, it's possible for myself or someone who compromised the database and has the right skills to decrypt the file without having to spend too much time. If you have done this, you can disable it then tell me to purge all settings uploads from the database and I'll take care of it for you.

There are some other attack vectors, but I won't post them here, lol. They don't have anything to do with the file encryption, rather ways to use S+ itself to reveal sensitive data. You can send me a private message if you want to discuss those further. I might look into adding some additional security options to help mitigate those other pathways, sacrificing some functionality for security.

Code:
public static byte[] EncryptBytes(byte[] input, string password = null)
{
	UnicodeEncoding UE = new UnicodeEncoding();
	Rfc2898DeriveBytes pdb = new Rfc2898DeriveBytes(string.IsNullOrEmpty(password) ? Password : password, SALT);
	byte[] key = pdb.GetBytes(32);
	byte[] iv = pdb.GetBytes(16);
	byte[] openBytes = UE.GetBytes(EncryptedStart);

	RijndaelManaged RMCrypto = new RijndaelManaged();

	using (MemoryStream cryptOut = new MemoryStream())
	{
		using (CryptoStream cs = new CryptoStream(cryptOut,
			RMCrypto.CreateEncryptor(key, iv),
			CryptoStreamMode.Write))
		{

			BinaryWriter bw = new BinaryWriter(cryptOut);
			bw.Write(openBytes);
			cs.Write(input, 0, input.Length);
			cs.FlushFinalBlock();
			return cryptOut.ToArray();
		}
	}
}
Back to top
randomConstant  
#3 Posted : Thursday, January 27, 2022 6:10:09 AM(UTC)
randomConstant

Rank: Advanced Member

Reputation:

Groups: Translators, Approved
Joined: 7/17/2021(UTC)
Posts: 135

Thanks: 35 times
Was thanked: 18 time(s) in 15 post(s)
First of all huge thanks for the detailed reply and source code. Although I can't make much sense of it, I'm sure other users will make good use of it in future.

I was actually expecting to hear something like "We use military grade AES-256 encryption" because that's what most products advertise their security as Laugh

So I looked up RijndaelManaged.CreateEncryptor Method and found a Rijndael Class Reference which has a caution saying:
Quote:
The Rijndael and RijndaelManaged types are obsolete. Use Aes instead.


Then I did a quick search for Differences Between Rijndael and AES and found out that:
Quote:
AES is a United States federal standard, FIPS 197, which is a subset of Rijndael

Further,
Quote:
In the Rijndael AES variant the block size is restricted to 128 bits and key length to 128, 192 or 256 bits only.


So, if AES is a small subset of Rijndael, then why would Microsoft caution about the Rijndael Class that way? and redirect to AES which is its subset in the first place.

I guess I'm just confused about this little bit. Also I can't tell if S+ code is using block sizes of 128, 192 or 256 bit. Maybe there's something I'm missing, I'd appreciate it a lot if someone could elaborate on this.

Thanks
Back to top
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Privacy Policy | Powered by YAF.NET 2.2.4.14 | YAF.NET © 2003-2024, Yet Another Forum.NET
This page was generated in 0.148 seconds.