/sci/ - Science & Math

>>1857804
how does it encrypt?

can't run it on my mac
will do later on windows comp!

>>1857818
It's not the executable, it's an encrypted text file, but ok. I will wait then.

>>1857823
Well, I wonder if you could guess it somehow. I want to know if it's hard to decrypt or not... If I tell you, then it would be very easy...

I can only tell you that it uses a password to encrypt the file.

haha encrypt a text file i will post contents

>>1857804

Post it on usenet's sci.crypt if you're serious.
But you're on 4chan, so of course you're not serious.

Anghenyyl V'z ubcvat ur jvyy cbfg vg gurer
gur synzrf vg'yy cebqhpr jvyy or zhpu orggre naq gb gur cbvag guna ur'yy trg urer.

>>1857849
so it has something to do with hex, ok.

What's with the .cbd? ububtu doesn't know what you're on about, and when I open it as txt no default encoding is found

>I want to know the strength of the encryption.

It is probably low, as the encrypted file is repetitive. A well-encrypted file would appear totally random, but I can see patterns in yours.

>If I pass you an encrypted file, could you decrypt it?
Probably not. Even the best cryptanalysts require more data than this to decrypt something.

The best way to determine the strength of your encryption is to discuss the algorithm. The most popular encryption algorithms (RSA, AES) are unbreakable even when the attacker knows the algorithm.

Yea, tryd it on mac anyway, never seen fucking .cbd before, can't even open it as text ><

>>1857864
Well, what you say is true. It's very very simple. But as you say, the hacker must know the algorythm, right?

So even if it's very simple, if the hacker doesn't know my algorythm or he can't recognise it, it will be almost undecryptable, right?

>>1857804

I don't even need to look at the file to know that the encryption is crap. Designing real encryption is hard, and if you're asking n00b questions like "I want to know the strength of the encryption" or saying things like "If I tell you, then it would be very easy" then you don't know enough to design good encryption.

Some pointers:

1. If the encryption is any good, it doesn't matter if the algorithm is known.

2. If the encryption is any good, it should be able to withstand an adaptive chosen plaintext attack.

3. If you don't know what an adaptive chosen plaintext attack is, you aren't going to be designing a worthwhile encryption algorithm. It is an attack where you get to have plaintext of your choice encrypted with a given (but unknown) key, you get to see the resulting ciphertext, and you get to repeat the process, using the results of each step to choose the plaintext for the next step.
In spite of this, it shouldn't be possible to deduce the key significantly faster than by brute force.

4. The encryption algorithm itself is often less of a problem than how you use it. E.g. if it's a block cipher, using ECB mode is shit. If it's a stream cipher, it needs to be salted and you need a separate authentication mechanism to defend against substitution attacks.

all the characters have been shifted forward 8 letters. Punctuation has been kept, if the new letter is beyond z the alphabet starts again.

This could be bruteforced if I had the application that made it in about a minute

>>1857883
No, that's not encryption, but merely obfuscation. It's probably pretty easy to figure out. Real encryption is not made easier to decipher by knowing the algorithm.

>>1857883
>if the hacker doesn't know my algorythm or he can't recognise it, it will be almost undecryptable, right?

Wrong. A good cryptanalyst can reverse-engineer the algorithm from the patterns in the encrypted file. It may take him days, but a good encryption algorithm takes decades or longer to break with the help of supercomputers. I doubt anyone on 4chan is going to go to the substantial trouble of breaking this just to prove you wrong.

If knowing the algorithm is a problem, then once an attacker decrypts one message, the rest will be extremely easy. This is why good encryption algorithms rely heavily on the key. That way, a message with a new key will be just as hard to break as the first one was.

>>1857890
http://www.mediafire.com/?9jgqq33ynbl5vrw

Give it a try then. It's not what you say but... try it and tell me if you can do it in a minute.

>>1857896

I have to work more on it anyway. It's my first time doing this. But I am interested in this, and I wanted to know if you could decrypt it without any extra information, to know how much would it take to be decrypted. In other words, learn a little bit of reverse engineering for my projects.

Well, even if you know the algorythm, you have to guess somehow the password. It must be a little bit troublesome than I think, but I want to know how much troublesome.

if you need good encryption software, by the way, go for truecrypt. I use it to keep my stuff encrypted, and it's virtually unbreakable.

>>1857883
> So even if it's very simple, if the hacker doesn't know my algorythm or he can't recognise it, it will be almost undecryptable, right?

Wrong. A good cryptanalyst only needs enough sample data. Then it's just a case of performing statistical analysis until you find a measure which deviates significantly from random.

Hiding the algorithm only means that it takes more effort to break it.

Any algorithm where the key is shorter than the message is theoretically breakable. You can't "prove" cryptographic strength mathematically, you can only disprove it.

"Proving" cryptographic strength is like proving a scientific hypothesis: you try as hard as you can to falsify it. The more attacks that the hypothesis survives, the more reason to believe that it is true.

If you want to demonstrate the strength of a cryptographic algorithm, you should do everything possible to facilitate breaking it. Hiding the algorithm simply forces people to do more work. Apart from making it less likely that anyone will actually attempt to break it, it reduces the significance of whatever effort was expended. If I gave you a login shell on my computer and you still didn't manage to get root, that's far more significant than being unable to get root without such access.

>>1857923
7zip works under wine fine

>>1857912

he said one minute with a brute force hacking tool
it would probably take less than one minute

hydra<3

>>1857912
mind putting it in .zip? linux cannot into .rar

>>1857929
"package dependencies cannot be resolved"

>>1857923
Yes it can. I just did.

>>1857945
archive manager doesn't work
wine doesn't install

>>1857923
I would but it's a windows executable that uses .NET framework. You can't run it on Linux, not even in Wine (I think).

>>1857940
WORKS ON MY MACHINE
debian stable amd64

Seriously, if Debian stable can run it... well, hie thyself to /g/ and get some help.

>>1857912
> Well, even if you know the algorythm, you have to guess somehow the password. It must be a little bit troublesome than I think, but I want to know how much troublesome.

An "ideal" encryption algorithm is one where there is no method of decrypting a message faster than guessing the key by brute force. A good algorithm is one where the best attacks are only marginally faster than brute force.

Any algorithm can (theoretically) be broken by brute force if the key is shorter than the message. A one-time pad uses a key which is as long as the message, and cannot be broken even by brute force. The downside is that to securely transmit an N-byte message you must already have securely transmitted an N-byte key. This makes it impractical for most applications.

>>1857950
I was talking about 7zip under wine. I didn't realize you'd so deeply embedded windows garbage into your toy encryption program.

Oh my. .NET bytecode is quite different from Java.

Anyway, it's Algorithm, not Algorythm.

Probably has been said already, but post the source code.
If your encryption method is secure, we can't crack it just by knowing the algorithm.

>>1857950
There's Mono, it should run fine.

>>1857982
http://www.mediafire.com/?epecevw7dag9wxv

Here, have the source. Have in mind that I am currently working on it, so it has some bugs yet.

OP, if you want to learn about cryptography, read "Applied Cryptography" by Bruce Schneier. It's a very easy read and it's the standard introduction, and will teach you many tried and true algorithms and protocols, and teach you how to analyze the flaws in a cryptographic technique.

>>1858003
So if someone puts in a 1-character password, it becomes basically a cryptogram that people solve in the newspaper, and progressively harder with the length of password, but sill cyclical. It would be a fun challenge trying to solve by hand, with a moderately short password.

If you're interested in realy cryptography, read the book mentioned above.

Okay, I'll try to figure out the password for shits and giggles.

>>1858035
If people makes ASCII to Binary conversion in the newspaper, maybe, as long as they guess the password. But yeah, I will do what you're suggesting me.

Tell us at least the length of the password. I'm bored.

>>1858061
10 characters, 8 letters and 2 numbers. All of the letters uses some kind of "accent" (I don't know right now how you say that in english) like ´, `or ¨ .

>>1858085
OP: does it consist of 3 letters, followed by 1 digit, followed by 5 letters, followed by 1 digit, followed by 1 letter?

>>1858108
No, I said 8 letters and 2 digits like, for example, "abcdefgh12".

>>1858108
Er, those 5 letters should be 4 letters of course.

>>1857960
oh wait, never mind. I tried using the ubuntu software centre instead of just sudo apt-getting it. Turns out I needed libsound, or something

>>1858003
> www.mediafire.com

Right. Put it where no-one who actually understands computer security will get it. Picture related.

Pastebin, motherfucker. Have you heard of it?

>>1858153
Oh, for the love of god...

http://pastebin.com/jARVx9x2

Are you happy now? Just decrypt it already! I'm starting to think that it works better than I expected, even if it's a shit of an encrypter.

>>1858179
Somebody needs to learn how to program...

>>1858197
Someone needs to shut up and help me solve this.

OP: can you confirm or deny these preliminary results?
- the 6th character in the plaintext is a '!'.
- the 7th character in the plaintext is a ' '.
- the 13th character in the plaintext is a ')'.
- the 14th character in the plaintext is a ''' (quote character).
- the 20th character in the plaintext is an 'R'.
- the 21th character in the plaintext is a 'B'.
Positions counting from one, measured in bytes.

>>1858237
No, they are all wrong. But I will give you a hint.

The first two characters are a carriage return (enter). Then, the first letter is a 'T'.

Also, look at the source to see how it works.

>>1858237
This is the file:

http://pastebin.com/5UdKyaCF

I can't give you more information, unless you want to know the password, but that means you give up.

>>1858287
I can't find out the original password, because you're not actually using half the password. However, if you give me a newly encrypted file together with the first 7 bytes of the plaintext, I can decrypt the file for you.

>>1858323
oh u
Don't do it, I think I can give you the plaintext without that.
I'm almost there... I think.

>>1858328
To clarify: I (>>1858323) am not OP.

>>1858346
I'm aware, but I meant that OP shouldn't post the first 7 bytes of plaintext.
Nearly got it now, still need to fix a few bits, though.

There we go:
TILESETMAKER v 2.0
Changes from v1.0
Added
In Paint Tools :

Airbrush tool.(NEW)

Stamps: The stamps can be now of any size (not only 16x6). Also In File menu added a command to save tile set as stamp file.
In Special menu

Effects: Added a Fade out Effect.

Create a button: Now the button can have a Caption and the Shape of the button can be an ellipse or rectangle.

Grab an Icon from exe , dll or icl file.(NEW)

Symmetry (NEW)

Join Tiles (NEW)
In Edit

Paste: Now you can flip horizontal/vertical and rotate 90 degrees the clipboard picture.
Rectangle, Round Rectangle, Ellipse and fill option.

a)In picture fill you can get picture from clipboard.

b)You can fill with patent and edit the patents.
Tiles Menu

Duplicate Tile (NEW)

Import from Gif (NEW)

Save Tile to JPEG (NEW)

Save Tile as ICON (NEW) (the tile must be 32x32 size)
Animation

You can save the animation in a Gif file.
In "Tile Set"

You can move the tiles by Clicking with the Right Mouse Button.

In the "Test Tile Set/Edit an Image'

Added two buttons. One to Fill the Image with the selected Tile and one to fill the Image with a color.
Help file: A better help file.
Many other bugs fixed!

If you find bugs e-mail me at kzsite2@yahoo.com

In 8-bit encoding, the passbits are:
±nbTrhS

Even without the plaintext, I had isolated 6/8 by identifying the spaces in the text:
±nbTraß

The first two rules of encryption is that all patterns in the text (letter counts, spaces, and such) must be concealed, and possible patterns in the password must also be concealed... usually a password is first converted to a hash.

>>1858369
fuck yeah, go /sci/

>>1858369
Also, this is the (partial) password (hexadecimal):
F1 ?? FC ?? 62 ?? E9 ?? 72 ?? 68 ?? E0 ??...

Now. There are a couple of issues with the program.

First, the line:

enc_password = Encoding.Unicode.GetBytes(password);

This line converts the password into UTF-8, which means that the array against which the data is XORed is actually 20 bytes long. Then the line:

if (select++ > password.Length) { select = 0; } else { select++; }

This line will actually reset the counter after 21 bytes, not 20.

Back to the program, the 21-byte passphrase is:

f1 fc 62 e9 72 68 e0 f1 fc 62 e9 72 68 e0 f1 fc 62 e9 72 68 e0

The file is divided in blocks 21-bytes long and XORed with that phrase.

>>1858438
UTF-16 I meant.

>>1858438
It's just 7 bytes, actually.
When entering a password with 10 characters, only the bytes 0, 2, 4...12 will be used.

>>1858438
It's just 7 bytes, actually.
When entering a password with 10 characters, only the bytes 0, 2, 4...12 will be used.

>>1858438
Well that's just a one-time pad, if the passphrase were as long as the message.

>>1858654
He wasn't making any statements about the length of the message.

>>1858179
Yep, it's shit. It's just a polyalphabetic substitution cipher (vignere). IOW, a stream cipher where the PRNG is just the password being endlessly cycled.

bResult = Convert.ToByte(bytes[y] ^ enc_password[select]);

The biggest weakness in such a cipher is the fact that:

ciphertext[i] XOR ciphertext[i+len(key)] = plaintext[i] XOR plaintext[i+len(key)]

IOW, if you XOR the ciphertext with itself shifted by the length of the key, you get the plaintext XOR'd with itself shifted by the length of the key.

If you know the nature of the plaintext (e.g. it's mostly ASCII or whatever), you just need to try different shifts; when you get the right value, it will be obvious.

Once you know the length of the key, you just split the ciphertext into len(key) bins. E.g. if the password was 5 characters, the first bin would contain characters 0, 5, 10, ..., the second bin characters 1, 6, 11, ... and so on.

Then you just do frequency analysis on the bins to find the corresponding letter of the password.

If you don't have enough ciphertext for frequency analysis, you need to do a bit more work, but it's still not hard.

Thread too long...
OP, here's the thing...
You don't just make up an encryption algorithm and hope no one figures it out. The encryption algorithm itself must be public knowledge, or else it isn't useful. The goal is to find an algorithm that is as close to "one-way" as possible.

>>1858438
>>1860283

And, finally, what I wanted to hear. Thank you for your help. I only wanted to know how to reach to the password without knowing anything. This information will help me develop a good algorythm.

>>1857829
>If I tell you, then it would be very easy

Security through obscurity fail. Encryption should be strong when the method (but not the password) is known. Your program is shit unless its been tested with knowledge of the algorithm, because if knowledge of the algorithm can be used to easily break the security, then YOU can easily break the security, thus it isn't secure.

tl;dr encryption should be strong enough to protect against those who built the encryption