Author

Topic: is this encryption any good (nullius is welcome) (Read 286 times)

member
Activity: 210
Merit: 26
High fees = low BTC price
If you want everything to be packaged in a single executable file, you can use the .lib OpenSSL binaries instead of .dlls. Or https://stackoverflow.com/questions/18486243/how-do-i-build-openssl-statically-linked-against-windows-runtimecompile them from OpenSSL source yourself, if you don't trust whoever posted these.

Yes and thanks for the link so I will see if it's not too bloated and run some bench marks on the speed and will report back
with my findings.

Quote
The script assumes you are on Windows.
The script assumes you have Visual Studio 2010, 2013 or 2015 installed in all the usual places. Important: If you have a different installation folder, your mileage may vary
The script assumes you have downloaded an OpenSSL tarball, like this one.
The script assumes you have Python (2.7 or 3.x) installed and on your PATH
The script assumes you have 7-zip installed (doesn't need to be on your PATH)
You need Perl. For Windows, ActivePerl is probably the best choice.
You need Nasm.
Choose the script you want to use and edit it. For example, let's take a look at the top of rebuild_openssl_vs2015.cmd:

Me is not going to these lengths, I know nothing about Perl and was expecting a VS C# project to play with so maybe I will
have a quick search around and see whats going.

The download from David-Reguera went over 200mb and it contains hundreds of HTML files in the
vs-2010 folder but no solution file or project folder which is sort of a basic requirement for VS projects that
contains fifty C++ Header files alone.

I want something that's KISS but gets the job done

Back again.

Stackoverflow.com are mouth peaces for Microsoft, defenders of the faith like we have here with bitcoins and they won't hear a world said against
it's MS pay masters and reading a few posts on SO you get the impression that they discourage any encryption that does not fall back
on Microsoft's (un-trusted) black box code so I am not really finding what I am looking for but they are not alone, "The code project" is just as bad too.

Come on someone must have a bit of code written for windows that does encryption based on a Key and uses less than a hundred lines of
code that's fast enough for the job I want or has it all been scrubbed from the net making my theory quite plausible.

This code I wrote offers better security but it's too slow for 2mb blocks
Code:
public static byte[] Encryption(Privateaddress Keys, byte[] data,bool UsePublicKey)
        {
            BigInteger encData = 0;
            if (data == null) throw new ArgumentNullException("data");
            int maxDataLength = (Keys.KeySize / 8) - 6;
            if (data.Length > maxDataLength)throw new ArgumentOutOfRangeException("data", string.Format("Maximum data length for the current key size ({0} bits) is {1} bytes (current length: {2} bytes)",Keys.KeySize, maxDataLength, data.Length));
            BigInteger numData = GetBig(AddPadding(data));//Add 4 byte padding to the data, and convert to BigInteger struct
            BigInteger Exponent = StringToBig(Keys.Exponent);
            BigInteger Modulus = StringToBig(Keys.PublicAddress);
            BigInteger D = StringToBig(Keys.PrivateAddress);
            if (UsePublicKey)
                encData = BigInteger.ModPow(numData, D, Modulus);
            else
                encData = BigInteger.ModPow(numData, Exponent, Modulus);
            return encData.ToByteArray();
        }

Where is that rijndael dude when you want him  Cheesy

legendary
Activity: 960
Merit: 1028
Spurn wild goose chases. Seek that which endures.
Distributing apps with Dll's is a pain in the bum and I like just a single .exe these days.

Bit of a pain programming this way in visual studio but i just use project folders these days to separate the sections of the project.
If you want everything to be packaged in a single executable file, you can use the .lib OpenSSL binaries instead of .dlls. Or https://stackoverflow.com/questions/18486243/how-do-i-build-openssl-statically-linked-against-windows-runtimecompile them from OpenSSL source yourself, if you don't trust whoever posted these.
member
Activity: 210
Merit: 26
High fees = low BTC price
Never roll your own crypto, especially not your own algorithm. Merely shifting the bytes around, even with this odd / even conditional going on, is unlikely to beat the statistical analysis of a ciphertext, especially if you assume the algorithm to be known.

I'd follow Qoheleth's recommendation of simply using OpenSSL instead.

Yes I hear this and I admit that I am no crypto mathematics expert 

Key exchange is using Secp256k1 which i like, don't want nothing that is black-boxed, dills or anything from Microsoft because they might not be able to
crack Secp256k1 but then sending the exchanged keys to back-door bills ms-spyware kind of defeats the whole point but that's just what the code is doing
that I nicked the Secp256k1 code from does and it's a big red flag too me.

From the little bit I know I think I could do something much more secure using BigINT's but that's going to be slow on 2mb data blocks
that i intend mainly to be used for file transfer and sending large node lists.

I am keeping the sockets open (Not REST) so I can spice it up using injection in bi-directional bound sockets because clients also become servers in
what I am trying to build but instead of working as IP/Port like the internet works its going to be more like Secp256k1 public-key/service with possible
relays in the middle so that no node knows who is really requesting the data and the code is using keys from that key exchange and is not primary.

Really it's just the backbone network I am building that I intend to have as secure as possible so apps can be built on top of it
with all the encryption and node discovery work already done for the apps.
member
Activity: 210
Merit: 26
High fees = low BTC price
When dealing with large data, wouldn’t you use symmetric encryption / stream cyphers? Maybe triple-DES and similar? With asymmetric encryption, you loose a lot of time. Encryption with asymmetric keys is awfully slow, and only used for short chunks of data. If you definitely need asymmetric keys, think about exchanging a key between both parties to transfer a key, which is then used for symmetric encryption of large data blocks.

I didn't think it was that slow and the bottleneck is going to be sending the data across the wire so I use Gzip on the data first, encrypt and then send it out or write to file
however i did play around with pointers and unsafe/unchecked code in C# but it didn't speed it up really so i dumped that plan.
member
Activity: 210
Merit: 26
High fees = low BTC price
If you're worried about Windows's crypto APIs stealing your encryption keys, why not just link against OpenSSL? It's got DLLs available for Windows apps, and then you know you've got a decent algorithm at least.
Distributing apps with Dll's is a pain in the bum and I like just a single .exe these days.

Bit of a pain programming this way in visual studio but i just use project folders these days to separate the sections of the project.
legendary
Activity: 3122
Merit: 2178
Playgram - The Telegram Casino
Never roll your own crypto, especially not your own algorithm. Merely shifting the bytes around, even with this odd / even conditional going on, is unlikely to beat the statistical analysis of a ciphertext, especially if you assume the algorithm to be known.

I'd follow Qoheleth's recommendation of simply using OpenSSL instead.


When dealing with large data, wouldn’t you use symmetric encryption / stream cyphers? Maybe triple-DES and similar? With asymmetric encryption, you loose a lot of time. Encryption with asymmetric keys is awfully slow, and only used for short chunks of data. If you definitely need asymmetric keys, think about exchanging a key between both parties to transfer a key, which is then used for symmetric encryption of large data blocks.

Triple-DES is deprecated with AES being the successor. Both are using a symmetric cipher, so in this case AES would be preferable. OP's cipher is also symmetric, so it doesn't look like asymmetric encryption is needed for their use case. Good point about asymmetric encryption such as RSA generally being much slower than symmetric encryption though.
sr. member
Activity: 257
Merit: 343
When dealing with large data, wouldn’t you use symmetric encryption / stream cyphers? Maybe triple-DES and similar? With asymmetric encryption, you loose a lot of time. Encryption with asymmetric keys is awfully slow, and only used for short chunks of data. If you definitely need asymmetric keys, think about exchanging a key between both parties to transfer a key, which is then used for symmetric encryption of large data blocks.
legendary
Activity: 960
Merit: 1028
Spurn wild goose chases. Seek that which endures.
If you're worried about Windows's crypto APIs stealing your encryption keys, why not just link against OpenSSL? It's got DLLs available for Windows apps, and then you know you've got a decent algorithm at least.
member
Activity: 210
Merit: 26
High fees = low BTC price
Unfortunately I am being forced to re-invent the wheel because high usage of AES encryption on
a windows machine falls over, leaks memory and programs go bang and I needed something that
does not use Microsoft little black box software that is fast and can encrypt 2mb chunks of data blocks.

RSA encryption from Microsoft cannot be trusted.
Code:
RSACryptoServiceProvider rsa = new RSACryptoServiceProvider(512);  // Key bits length
rsa.PersistKeyInCsp = false;
The second line of code is needed because it use to default to true and resulted in the keys being
stored in windows certificate store and put quite simply Microsoft now steels anything it can lay it's hands on
and goes as far as to run web-dav at night to scan remote disk drives on your LAN.

Here is the function and it works by shifting byte code to the right based on the key with a bit of salt thrown
in for good measure and works with a variable length key that can be HEX or even XYZ
Code:
private static ushort[] MakeShiftKeys(string Key)
       {//Conver HEX keys to array of numbers but will also work for other letters too
           ushort[] Shifts = new ushort[Key.Length];
           for (int f = 0; f <= Key.Length - 1; f++)
               if (Key[f] >= '0' && Key[f] <= '9') Shifts[f] = ushort.Parse(Key[f].ToString()); else Shifts[f] = (ushort)(Key[f] - 55);
           return Shifts;
       }

public static byte[] EncryptFast(byte[] Text, string Key)
       {//About 10 seconds per gigabyte on I7 PC using 1mb blocks
           ushort[] ShiftKeys = MakeShiftKeys(Key.ToUpper());
           ushort Count = 0; ushort Shift = 0;
           ushort R = (ushort)(Text.Length % 8);
           if (R == 0) R = (ushort)(Text.Length % 3);
           bool Even = R == 5;
           for (uint f = 0; f <= Text.Length - 1; f++)
           {
               if (Count != R) Shift = ShiftKeys[Count];
               else if (Even) Shift = 77;
               else Shift = 66;
               if ((byte)Text[f] + Shift + R <= 255) Text[f] = (byte)(Text[f] + Shift + R);
               else Text[f] = (byte)((Text[f] + Shift + R)-256);
               Even = !Even; Count++;
               if (Count > Key.Length - 1) Count = 0;
           }
           return Text;
       }

During tests this code was found to be 40% slower than using Microsoft AES function and this is because
using C# and byte arrays you have to cast the byte to an INT32 to preform sums so maybe I can fix it using
UN-SAFE section of code if I can remember enough C++.

Previously I have played around with BigINT and MOD but this was not fast enough for big blocks of data
and I know the above is not military grade encryption but how would you rate it and what can be done to
make it better without taking too much of a performance hit.

I was thinking of compressing the data using Microsoft's GZip before using this encryption function which can be done
by using just four lines of code.

Quote
MemoryStream MS=new MemoryStream();
using (GZipStream gz = new GZipStream(MS, CompressionMode.Compress, false))
               gz.Write(Data, 0, Data.Length);
return MS.ToArray();  

But given the amount of network activity that I see coming out from my machine from millions of Dll's
running inside surrogate processes that we have no control over anymore I think I would roll my own compression
if I could do it in under a months work.





Jump to: