Index
> Main > Philosophizing about cryptography...Goto page 1, 2, 3 Next |
| Author |
|
|
edfed 02 Mar 2008, 21:49
ok; let's go.
but how does it work exacttly, the compressing cryptography? |
|||
02 Mar 2008, 21:49 |
|
|
AlexP 02 Mar 2008, 22:11
OK; It's on
Compressing cryptography? By that do you mean a cipher smaller than today's, yet stronger? The world just needs to realize that human lives are dispensable, knowledge is not. Once more people realize that, they can solve problems like this. EDFED: Okay, I just saw an instruction and I need an experienced person to tell me: What works better, Code: movzx ebx,al mov al,[Table+ebx] movzx ebx,ah mov ah,[Table+ebx] ror eax,16 movzx ebx,al mov al,[Table+ebx] movzx ebx,ah mov ah,[Table+ebx] ; or: mov ebx,Table xlatb ror eax,8 xlatb ror eax,8 xlatb ror eax,8 xlatb Just saw this instruction, was wondering if it was faster or slower to use (in the long run) |
|||
|
02 Mar 2008, 22:11 |
|
|
bitRAKE 02 Mar 2008, 22:20
The standard argument of reduction is the Pigeonhole principle, or closely related Birthday paradox. We have a range of information to compress (encrypted or not) and the only way to do so it to reduce the range of allowed messages (definition of compression). Otherwise it cannot be compressed. Data modeling can reduce the description of a message by taking advantage of constants (non-randomness) within the information.
The transformation applied by cryptography could also be a compressive model. The algorithm is fed some data and it returns the password and compressed data. Edit: fastest to keep the bytes separate, Code: movzx eax,[Tab+eax] movzx ebx,[Tab+ebx] movzx ecx,[Tab+ecx] movzx edx,[Tab+edx] Code: push eax mov [esp+1],bl mov [esp+2],cl mov [esp+3],dl _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup Last edited by bitRAKE on 02 Mar 2008, 22:33; edited 1 time in total |
|||
|
02 Mar 2008, 22:20 |
|
|
edfed 02 Mar 2008, 22:25
the faster is to make an algo that generate the table automatically.
as in my cryptography post, i've posted some month ago a thread about cryptography based on RANDXOR. it is convenient for undecryptable files as it is based on pseudo rand generator and xor instruction. note this thread never saw any reply,  
as you can see, the pseudo random generator can generate a lot of bytes from only four bytes (the seed) as it is not random, one start dword wil give an unique long sequence of bytes, very long. we can probably make a compression based on random generation. for example, a simple string: 'abc',0 this will be a generator that starts at a, makes two inc, and then, end with 0. this is basically a reverse code generation. an attempt to make some IA, as Human Intelligence can be interpreted as a recomposition of large amount of data in algorythms. like this wall is 50 meters long, it is composed with 25*50 cm brutes bricks, and then, the memory regenerate an image of the wall. or sounds, we memorise sounds like samples in an electronical mix, with lyrics memorised as text instead of .wav. |
|||
|
02 Mar 2008, 22:25 |
|
|
f0dder 02 Mar 2008, 22:54
edfed: and this shows why you shouldn't trust encryption to random, unqualified people
First of all, a PRNG is that - PRNG, not RNG. And the P is for pseudo, not pure and certainly not perfect. There's a risk it will repeat at some point. Furthermore, 32bit seed - that means a 32-bit key... a lot more feasible to bruteforce that than a 128- or 256-bit key space. If you want really simple XOR encryption, you need to make sure they keystream is as long as the datastream, and that each keystream is only ever used one time... this is called a OTP, or one-time pad. It's very unweildy in the real world though, and people often end up being slightly careless... whoops!. |
|||
|
02 Mar 2008, 22:54 |
|
|
AlexP 02 Mar 2008, 23:04
Or just give everybody who needs security a chunk of uranium and corresponding usb cord for a RNG
|
|||
|
02 Mar 2008, 23:04 |
|
|
f0dder 03 Mar 2008, 00:27
AlexP wrote: Or just give everybody who needs security a chunk of uranium and corresponding usb cord for a RNG _________________  - carpe noctem |
|||
|
03 Mar 2008, 00:27 |
|
|
bitRAKE 03 Mar 2008, 01:38
Which is the whole problem with OTP, and the reason for this thread?
Quote: This is the only provably secure cryptosystem we know of. _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
|
03 Mar 2008, 01:38 |
|
|
revolution 03 Mar 2008, 01:55
AlexP wrote: Why not someone develop a contest (like AES), to design a cipher that is elegantly tiny, but more powerful than any other today. Whenever I see some random hackers website selling a program to protect my precious data with his own "secret" encryption scheme I cringe with dismay. I wonder how many people fall for this type of thing and trust their data to an unknown algorithm of unknown quality. BTW: I use truecrypt, open source, known algorithms, no bullshit, just simply works well without fuss. |
|||
|
03 Mar 2008, 01:55 |
|
|
edfed 03 Mar 2008, 02:06
the 32 bit key is just an example, it can be expanded to how many bits you want, just, you need to modify the PRNG to work on larger seeds.
the seed is builded with a char string, like a password, a keyword, or anything else. the crytpted fiel can contain the next seed for the next communication (it is a basic trick), and the best, it is to encrypt the algorythm too. then, the message can contain some keywords to say: the next PRNG will generate the pad with: Code: mov eax,[seed0] xor eax,[seed1] xor [file+edi],al xor [file+edi],ah xor [seed0],eax ror eax,7 xor [seed1],eax or anything else. then, the message will be hard to find.. |
|||
|
03 Mar 2008, 02:06 |
|
|
revolution 03 Mar 2008, 02:10
edfed: you are describing a steam cipher, like RC4. Even block ciphers can be used as stream ciphers with the right parameters.
|
|||
|
03 Mar 2008, 02:10 |
|
|
AlexP 03 Mar 2008, 02:52
Revolution: TrueCrypt is definitely the best example of great user experience I have ever seen. Just wanted to throw that out there.
Oh yeah, and Einstein says: "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." This is what I meant by this thread. |
|||
|
03 Mar 2008, 02:52 |
|
|
daniel.lewis 03 Mar 2008, 04:57
 Good post, rev.
My personal preference is with ciphered reference Beale ciphers. If you want an added level of security, you can make it multi-party, and then no single party can reveal the plaintext. All the 128-bit, or 1024-bit encryption schemes fail in that they are ultimately computable from ciphertext. Beale Ciphers and One Time Pads are not. - take alternating bits of your text and x. 'and' the odds, 'or' the evens. - this time, 'and' the first 4 bits, xor the rest. This means the interceptor needs to recover the cipher data, the mask data, and the binary op pattern that is being used. Enjoy. _________________ dd 0x90909090 ; problem solved. |
|||
|
03 Mar 2008, 04:57 |
|
|
f0dder 03 Mar 2008, 12:55
edfed wrote: the 32 bit key is just an example, it can be expanded to how many bits you want, just, you need to modify the PRNG to work on larger seeds. |
|||
|
03 Mar 2008, 12:55 |
|
|
r22 03 Mar 2008, 14:44
http://board.flatassembler.net/topic.php?t=6518&postdays=0&postorder=asc&start=0
(last year) Computers can't perform miracles, encryption will always need a lock (the algorithm) and a key (the password/seed/smart card), although public/private key encryption is a little different. If you want to learn a little about symmetric encryption the thesis (3rd or fourth post down) I posted to the thread linked above is pretty thorough. It also makes an argument for large key size while still having great performance. Using a BYTE-to-BYTE LUT is totally insecure. MOVXZ ebx,byte[TABLE+ebx] BAD -255 possible values -To DEcrypt you need TABLE's inverse -Known source can be used to attack it --Say an EXE is encrypted you can predict most of the PE header bytes and use those to reverse most of the LUT. -If you make the LUT bigger WORD-to-WORD your key (the LUT) becomes larger than a normal encryption key and the known source attack will still work. PROE (the algorithm in the thesis linked above) uses a verified PRNG (verified by NIST randomness testing suite) and was coded specifically for x86-64 systems using SSE/2. |
|||
|
03 Mar 2008, 14:44 |
|
|
Chewy509 03 Mar 2008, 23:45
AlexP wrote: Something that's been on my mind for years, I just thought I would throw it out there so I could see what other people think of the matter(s). 1. The only known and proven secure system is OTP - however OTP is impractical for the general populous. (most militaries/defence forces still use it). 2. The RSA public key encryption system is beautifully simple, however have an inherit weakness, that the public key is derived from your 2 private keys. (Why are we using it, because factorisation of large numbers requires brute force effort - and we are using very large numbers eg. 2^4096 large). 3. Most if not all modern day ciphers are attacked/tested by hitting the algorithm first, then by brute force. DES was broken by hitting the algorithm. (Decrypting DES is a 1pass solution now - you don't need the key). 4. Super-Encryption (aka using 2 different ciphers and 2 different keys) works well... (This is essentially 3DES - you run the data through DES 3x times with 3 different keys). 5. The main problem with private key based crypto-systems is key-exchange. (Solve this and the NSA and every other government agency will make you a god). Public key - well see point 2. 6. Quantum based crypto-systems are still in testing, however are proving extremely efficient and easy to work with. 7. AES works well, but due to limited key space is venerable to brute force attacks due to cpu speed. |
|||
|
03 Mar 2008, 23:45 |
|
|
f0dder 04 Mar 2008, 00:14
Chewy509 wrote: 7. AES works well, but due to limited key space is venerable to brute force attacks due to cpu speed. |
|||
|
04 Mar 2008, 00:14 |
|
|
edfed 04 Mar 2008, 00:23
hem...
imagine, the randxor used with very long seed PRNG. then, the seed is the password. this password can be crypted too with another seed. with an algorythm contained in the dataflow. the streaming generated by the high speed communication will contain some variable algorythms, and not yet efect commands. like in 10 minutes, the algorythms used the 23 december 2007 at 0:32 is used. this message will be sent at any time in a particular form. with an other seed. hem...good night. |
|||
|
04 Mar 2008, 00:23 |
|
|
vid 04 Mar 2008, 00:56
edfed: You can crypt the value over hundred times, that doesn't change anything. All that matters is how much truly random information you have in beginning. Predictably switching several predictable operation with predictable (non-random) data doesn't improve security at all.
And, as f0dder pointed out, PRNG doesn't generate random data at all. |
|||
|
04 Mar 2008, 00:56 |
|
| Goto page 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|