xor cipher

conceited

How hard would it be to break this encryption.(nsa for example)
A 16bit key that is as long as the message it's encrypting and never uses the same key.

Thomas_S_Hunterson

Well AFAIK, with a single use key the same length as the message, the encryption should be unbreakable as long as the key remains private assuming brute-forcing is unfeasible (which most likely, given a message long enough, it is) and there is no known plaintext.

Although I don't know much about encryption, so take that with a pinch of salt.

probe

conceited wrote: »

How hard would it be to break this encryption.(nsa for example)
A 16bit key that is as long as the message it's encrypting and never uses the same key.

Please see http://en.wikipedia.org/wiki/One-time_pad - it looks similar.

.probe

Martyr

check out codebook solutions

here is C code to solve XOR cipher algorithm.(it has 160-bit key limit)

frequency analysis

conceited

Thanks for the info lads, will read them links aswell .

AARRRGH

conceited wrote: »

A 16bit key that is as long as the message it's encrypting and never uses the same key.

I assume you're saying the key is used once and then discarded?

If that's the case, it'd be nearly impossible to crack, HOWEVER...

If you are encrypting text rather than a garbled binary file, I could have it cracked in a few minutes. Two reasons -

1. A 16 bit key is too small -- I could brute force attack every possible key in a few minutes.
2. I'd write my attack code in such a way that when every potential key is tried, I pattern match the decrypted text to search for dictionary words. If a match is found, I save the text in a "potential plaintext" file. When every key has been tried, I take a quick look at the potential plaintext files to see which one is the correct plaintext.

So your idea is good -- using the key once is very secure -- but your key size is too small.

Martyr

well..16-bits is only 2 bytes, with 65,536 possible keys...

found this Classified Crypto algorithm by NSA

its the best of..

comment #
   
    WARNING *** CLASSIFIED CRYPTO, NOT FOR EXPORT *** WARNING
    
    This is part of project X, cryptography division.
    I am professor Fox Mulder, head of cryptography division.
    
    This is latest advancement in encryption, state of the art
#

encrypt proc output:dword,input:dword, datalen:dword

    mov esi,[input]
    mov edi,[output]
    mov ecx,[datalen]
encrypt_loop:
    lodsb
    xor al,80h
    stosb
    loop encrypt_loop
    ret
encrypt endp

Thomas_S_Hunterson

AARRRGH wrote: »

2. I'd write my attack code in such a way that when every potential key is tried, I pattern match the decrypted text to search for dictionary words. If a match is found, I save the text in a "potential plaintext" file. When every key has been tried, I take a quick look at the potential plaintext files to see which one is the correct plaintext.

Surely if one is using a random key the same length as the message, brute forcing will just turn up every possible combination of letters/symbols, and you'll end up with every possible combination of dictionary word matches.

AARRRGH

Well, I would think it is unlikely a few keys will generate plaintext which is mostly readable English, so if you set your "check for English words" code to only save plaintext which has a number of English words I reckon it'd be fairly reliable.

Basically what I'm trying to say is if you want security you need to use large keys!