topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday March 28, 2024, 5:49 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: This is an entry for NANY 2019 - SCrypt  (Read 12941 times)

KodeZwerg

  • Honorary Member
  • Joined in 2018
  • **
  • Posts: 718
    • View Profile
    • Donate to Member
This is an entry for NANY 2019 - SCrypt
« on: June 16, 2018, 06:21 PM »
Hello all,
i like to introduce a small tool that i just finished and Contribute to Nany 2019.

Toolname: SCrypt.exe / Small File Cryptor
Target: Console Application
Compiler: Delphi 7 32bit
Whats the Point: It'll encrypt/decrypt a file
Project-Status: early Release, Basics should be final
Extras: Utilize MMX features, wasted time display for encoding/decoding
Limits: Untested max. Filesize, my guess is 2GB Limit, keys are fixed ATM (internal using a set of 4)

Source: not included, not avail by request.

Usage:
SCrypt.exe FileToTest.Ext

My App will never change Original File!
It will produce/overwrite two new Files:
1. FileName_ENC.ext = Original File in encrypted Format
2. FileName_DEC.exc = restored encrypted file

Tested with Windows 7 x64, Application might need Admin-Rights to create Files.
If you have wishes, suggestions or found a bug, drop a line, thanks!


!!!Attention Interested SCrypt Users:
This tiny tool does NOT provide much security!
Everyone who has this App can reverse any crypted file back since i do not provide Password crypting!!!!
For myself it was educational testing of MMX Chipset features to benchmark vs other Cipher/Crypter methods.
Anyway, decrypting a file by hand it is still not that easy like someone might think.

My Tool-Name has nothing to do with anything else called SCRYPT, its just short for "Small File Cryptor".
« Last Edit: July 17, 2018, 04:14 AM by KodeZwerg »

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #1 on: July 16, 2018, 12:09 PM »
So... what's the point? :-)

You don't support a passphrase, which means there isn't really any security.

You don't mention which encryption algorithm is used, making it hard to reason about the security if you implement key generation from passphrases later on.

Encryption a 4k text file full of 'A's makes it clear that you're using a 32-byte block size with no block chaining, which means that even if you use a decent encryption algorithm, your encryption as a whole can be broken.

So... this sounds like something that's probably a fun project, and where you might want to share the code with other people and learn from the experience.

But not a good idea to present it as a utility for other people.
- carpe noctem

KodeZwerg

  • Honorary Member
  • Joined in 2018
  • **
  • Posts: 718
    • View Profile
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #2 on: July 16, 2018, 03:30 PM »
Whoa, thanks for trying out and give feedback.
For me it was educational to learn how MMX works. It does exact what i've written what it does.
My intention was not to create a fullprice Protection Suite.
For myself i've included it in my Apps that transmit something via Internet.
Your point "it can be broken" i just can silly argue "what cant be broken?".

If interested i can publish a not that fast version with Random output, also for "1000 times "a" in a file" with same passphrase encrypted, each time unique encrypted results are given. That is a bummer to decrypt without my App and seems to be very safe due each time you encrypt something the result is different. If thats what you like/need/want, i could split up an existing Application where i've included such feature already.

Jibz

  • Developer
  • Joined in 2005
  • ***
  • Posts: 1,187
    • View Profile
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #3 on: July 17, 2018, 03:55 AM »
f0dder's comments may be a bit direct, but try to take them as constructive criticism.

Writing your own encryption is a great project, but when you make it available for other people to use, it becomes important to be clear about the level of security. This is because a false sense of security is worse than no security. Imagine a person who downloads your program, encrypts all his banking information using it and sends them over email.

Cryptography is hard, and even seasoned programmers sometimes fall for Schneier's Law. That is why it takes years of public scrutiny and analysis for any algorithm to be widely accepted.

And even if you use algorithms generally accepted to be secure, there are details surrounding their use and combination that can compromise the security (like using an insecure source of randomness, storing plain password hashes, or using a block cipher in ECB mode).

Please note again that I am not saying you shouldn't continue working on your project -- I think it is great you wrote this and chose to make it available for NANY! Just make sure potential users are aware of it if you came up with your own encryption algorithm, and know whether the goal is to keep their family members or professional cryptographers from being able to read the file.

On a side note, there is a key derivation algorithm called scrypt.

KodeZwerg

  • Honorary Member
  • Joined in 2018
  • **
  • Posts: 718
    • View Profile
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #4 on: July 17, 2018, 04:17 AM »
Thank you Jibz, i've updated Post #1 to ensure everyone knows such information before anything bad happen.

Ps: It is custom algorithm.

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #5 on: July 17, 2018, 04:17 PM »
As Jibz say, I'm pretty direct ;)

Take it for what it's meant to be - honest advice, not an attempt at saying you're stupid or that what you've made is worthless. Jibz put it a bit more eloquently, and you should definitely take his advice to heart.

But let me elaborate a bit.

The "hard" thing first: your method is not secure, and it is not practical. Whether "secure" matters depends on your threat model, but there are many other solutions out there that are both convenient and offer hard cryptographic security.

And then on to some words of encouragement: playing around with crypto is fun. Try doing stuff on your own, see what other people have done. Optimizing is fun, and going assembly-level with interesting instruction sets even moreso. Don't stop being interested in these things!

The best thing you can do with this NANY entry is to share the code. Talk to other developers. Accept criticism, learn from it. There's a good chance you'll end up learning stuff about encryption as well as optimizing.

For fun, I've attached a couple of files from 1997 when I thought I had designed a super cool crypto scheme.
- carpe noctem

KodeZwerg

  • Honorary Member
  • Joined in 2018
  • **
  • Posts: 718
    • View Profile
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #6 on: July 17, 2018, 08:18 PM »
As Jibz say, I'm pretty direct ;)
That is absolutely okay to me. Better direct than writing dozens lines of lovely text with small real consumable feedback.
Take it for what it's meant to be - honest advice, not an attempt at saying you're stupid or that what you've made is worthless.
All is fine, no offend taken.
The best thing you can do with this NANY entry is to share the code.
I am sorry, this option is gone. While developing/learning MMX it was possible. When i published it here it was possible to get code. Now the Crypt-Algo is already bound to another Application. I try rebuild something similar to share as code not as binary. I am sorry!

I am pretty sure you have code anyway :-)

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #7 on: July 18, 2018, 12:49 AM »
I am sorry, this option is gone. While developing/learning MMX it was possible. When i published it here it was possible to get code. Now the Crypt-Algo is already bound to another Application.
Why does that change anything?

I am pretty sure you have code anyway :-)
It would be easy enough reverse-engineering it - but it's not that I'm particularly interested in the algorithm. Sharing it would be for your own good, to learn from the discussion you could have with more experienced developers :)
- carpe noctem

KodeZwerg

  • Honorary Member
  • Joined in 2018
  • **
  • Posts: 718
    • View Profile
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #8 on: July 18, 2018, 04:28 PM »
Why does that change anything?
Source now dont belong to me anymore. It is now part of another Application/Company.

Crush

  • Member
  • Joined in 2006
  • **
  • Posts: 402
  • Hello dude!
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #9 on: August 22, 2018, 06:25 AM »
You really should post at least some relevant code fragments, otherwise noone will believe that you´re doing really a usable encryption. I also posted such an experimental (super-)encryption tool a few years ago and it was necessary to publish the source also.
The same problem came up with a game solving AI robot at a coding contest. Nobody believed that I was able to find the best solution within a few nanoseconds while the best were not able to break the milliseconds barrier and some others needed several seconds. They didn´t believe that this is technically possible until I released the sourcecode.

KodeZwerg

  • Honorary Member
  • Joined in 2018
  • **
  • Posts: 718
    • View Profile
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #10 on: August 22, 2018, 01:57 PM »
You really should post at least some relevant code fragments, otherwise noone will believe that you´re doing really a usable encryption. I also posted such an experimental (super-)encryption tool a few years ago and it was necessary to publish the source also.
The same problem came up with a game solving AI robot at a coding contest. Nobody believed that I was able to find the best solution within a few nanoseconds while the best were not able to break the milliseconds barrier and some others needed several seconds. They didn´t believe that this is technically possible until I released the sourcecode.
Okay, here we go
Code: Delphi [Select]
  1. type
  2.   AllBytes = array of Int64;
  3.  
  4. var
  5.   i, NumOfBytes : Integer;
  6.   NextKey, CurrentByte : Int64;
  7.  
  8. procedure Crypt(var ManyBytes : AllBytes);
  9. begin
  10.   for i := 0 to NumOfBytes - 1 do
  11.     begin
  12.       CurrentByte := ManyBytes[i];
  13. //      NextKey := *removed*
  14.       asm
  15.         MOVQ mm0, NextKey; // <- store NextKey
  16.         MOVQ mm1, CurrentByte; // <- store CurrentByte
  17.         PXOR mm1, mm0; // <- at this point we have XOR cryption done via MMX
  18.         MOVQ  CurrentByte, mm1; // give result back
  19.         EMMS;
  20.       end;
  21.       ManyBytes[i] := CurrentByte;
  22.     end;
  23. end;
That represent main crypto part. Feel free to use or examine. I've slightly commented it.
Only missing Part to get it straight working is my Array for NextKey Values.

Crush

  • Member
  • Joined in 2006
  • **
  • Posts: 402
  • Hello dude!
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #11 on: September 01, 2018, 06:27 AM »
Looks like a straight forward xor from byte to byte - no salt, password or any other "security". No complex code and I see no higher protection. Bad to read, but not too hard to crack. The "real" scrypt is incredible much better. There´s a lot of space to improve your method - do this with an additional keyword that you procede the same way.

KodeZwerg

  • Honorary Member
  • Joined in 2018
  • **
  • Posts: 718
    • View Profile
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #12 on: September 01, 2018, 02:15 PM »
For the type of how it is used here, it is more than good enough. Intention was to (client side) crypt on the fly, send data via udp or tcp/ip, (server side) decrypt on the fly, done. Imagine a crypted Chat-Session for example. What i wrote in Post #1 should match. I am no expert but have experience and always interested in other ways to reach goal. My goal was to quick de-/crypt data, nothing more nothing less.

For a crypto competion i have talent enough to create something way better, but that was not focus of this project, just speed.

Crush

  • Member
  • Joined in 2006
  • **
  • Posts: 402
  • Hello dude!
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #13 on: September 03, 2018, 03:01 PM »
For speed there´s still place for optimization  :D

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: This is an entry for NANY 2019 - SCrypt
« Reply #14 on: May 23, 2019, 02:12 PM »
I hope your "NumOfBytes" is badly named, and is really "NumOfInt64Blocks" :-)

Unless your "//      NextKey := *removed*" fetches a value from a One-Time-Pad with the same length as the data you're encrypting, that you're never re-using the OTP, and that you have a guaranteed non-surveilled channel for getting the OTP to the other side... then this is pretty useless.

I'm sorry if "useless" seems like a harsh word, but it's true nonetheless. If there's any reason to use crypto at all, use proper crypto. A scheme like this is definitely not good enough for "a crypted Chat-Session" - if you're discussing sensitive matters you need a whole lot more (there are perfectly good reasons Signal has a complex protocol), if you're not... well, who cares, send plaintext or use a HTTPS connection. Doesn't matter much if NSA knows when you're gonna hook up with your girlfriend, or what groceries you need to pick up on your way home from work :-)

Also, the code is pretty slow - no loop unrolling, and EMMS'ing for every block? Ouch! :)
- carpe noctem