SIN - Safety In Numbers

Posts 1–15 of 15 · Page 1 of 1
SIN - Safety In Numbers
SIN is a program made by me to battle draconian anti-piracy plans that threaten to disrupt free-speech and freedom of information. Basically SIN is a file server and client in one compact executable. SIN combines 4096 bit RSA and 256 bit aes-rijndael to form a very strong hybrid cryptosystem so that even governments and security agencies can't break your encryption in the next 50isch years or so.

For comparison: 1024 bit RSA is considered secure for the next 10 years and SIN uses keys four times as large. Aes rijndael is used by the US government's messages with top secret classification. Some have said that it would take 149 trillion years to brute force Rijndael

Warning: SIN is designed to ensure safe file transfer, it's not meant to keep the files themselves safe. This means that while an agency or government cannot decrypt data captured on line, they can simply connect to your server and download the files themselves. You'll want to share files that are encrypted before they are stored in the Shares folder. Truecrypt and Winrar could do this for you.

Why not just encrypt it and store it on a http fileserver instead?

There are two reasons, the first being that if a file -encrypted or not- is found to 'violate' intellectual property 'laws' it's often taken down immediately. This means that you will not be able to recover it once it's found to be violating some law or another. It's even worse when the site (this happened to various filesharing sites) has to chose between releasing personal details -like your ip address- or face a lawsuit. Even if they have nice privacy policies you should bear in mind that these mostly involve you and that the site itself can violate them in any way they see fit.

Secondly because a file, no matter how many times it's transported, always looks different when using SIN. This is because SIN uses a Onetimekey used only for the current connection. Even If they suspect you're downloading a copyrighted file they cannot prove you did. Because the file will look different every time it's downloaded.

tl/dr: Use SIN it's better then http filesharing.

The program expects two arguments:

Code:
SIN s <- this starts the server on your local ip (not 127.0.0.1) on port 4040

SIN c ip-here port-here <- connects the client part to another server on ip and port (port is always 4040 for now)
The program will create three new folders the first time it is ran, one is named Imports and the other two are named Shares and OneTimeKeys. In shares you'll put all files you want to share with other people when they connect to your server. In imports all the files you download will be saved. If you run the server (SIN s) a file named 'shared' will also appear. DO NOT MOVE, COPY OR EXPOSE THIS FILE TO ANYONE! if this file is exposed all your data can be decrypted beating the point of the whole program. Just keep it exactly where it's at and everything will work as it should.

SIN.exe - Jotti's malware scan
https://www.virustotal.com/file/b235...is/1328263270/

Pic1 :



Pic2:



Commands:

Client commands:

g -> gets all files in the server shares folder
d -> Download a singe file
e -> Exit

Server commands: None

-SCHiM
SIN.rar2.1 MB · 25 downloads 1/62 malicious
Very good job

Will it cause a major speed decrease?
Not much of a speed decrease no. Because the program is loaded into memory and encrypted and then sent over the wire.
What if it is a huge file, like a os image on 3 gb?
I don't know, haven't tried it with huge files. The biggest I tried was a 27mb mp4 movie. It went very smooth and the video was unchanged.
Great Job. I think I'll give it a try ;]
What i meant was you said you load the file to the memory before sending it. What if a 3 gb file is loaded to the memory?
2 weeks later, still waiting for above post's answer ^^'

I guess I'll try to contact schim myself at this point and ask him if he uses a file-cache already to avoid large files using all the computer's memory for large file encryption.
Big files will fail, I just tested it, and the problem is memory allocation. I can post the code if you're interested so you can tweak it to work with bigger files if you want, since I've moved on to another project now.
Yes, please post the code would be great.
I vm'ed you with a link to the code and a general explanation of why I use RSA and Rijndael in response to your message.
Why not break up bigger files into smaller payloads and encrypt each one? So at any point in time you only have say... 1MB (just a random value) of the actual file mapped into memory, you then send that off and prepare the next payload. The client then receives each payload, decrypts it, and then writes it so it doesn't have to store the whole file either.
Exactly my thought. I was thinking reading the file line by line. Encrypt each line and then send it to the client and proceed to the next line. The client will decrypt all the incoming lines and write the binary to a file, or write all the binary data to a temporary file and then line by line encrypt the file to cut down on the upload/download time.
Quote Originally Posted by Variant View Post
Exactly my thought. I was thinking reading the file line by line. Encrypt each line and then send it to the client and proceed to the next line. The client will decrypt all the incoming lines and write the binary to a file, or write all the binary data to a temporary file and then line by line encrypt the file to cut down on the upload/download time.
Rather than treating the file as text, treat it as raw binary and just read fixed-size chunks from the file.
I would have done that yes, had I had larger files in mind. But the truth is that I was more focused on the protocol itself then the files it was going to send (and it's not much of a protocol)

Here's the source: [Ruby] SIN-source - Pastebin.com

This is not the same source as the binary posted, rather here I've begun to implement the chunked transfer but never finished it. I've stopped on this project as Sopa/acta/pipa where not passed/are put on hold. When the serpent rears it's head again that's when I'll go back in too
Posts 1–15 of 15 · Page 1 of 1
This thread is closed for replies.

Similar Threads

Talk with us