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

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.


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

Where is that rijndael dude when you want him  

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 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.

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.

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.

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.



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.

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.

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.

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.
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

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.


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.