flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2 |
Have you utilized this in your programs? | |||||||||||||||||||||
|
|||||||||||||||||||||
Total Votes : 5 |
Author |
|
Madis731 17 Jan 2008, 06:45
Should I....okay - I already copied the link - so why not
![]() http://en.wikipedia.org/wiki/Little_endian ...paste it... |
|||
![]() |
|
revolution 19 Jan 2008, 16:47
AlexP wrote: Well, endianness is used only within 32-bit values themselves (in that architecture), right? But what about the endianness of multiple dwords? It makes for prettier code when working with big numbers, but I can not see any other real improvement... Anyway, I have a question (yes, again) for people who have done any cryptography algo's lately: I noticed that the actual encryption does not have to be more than a Ceasar Cipher to provide enough security, because I had a thought that if the key schedule was resilient enough, it could provide a (hopefully nearly-unbreakable) data stream the same size as the input. So a good key schedule (combined with a cipher as easy as a Ceasar) would be a One-Time-Pad, except with the key able to be brute-forced in all cases. I combined the key schedules of Rijndael and Serpent and I think it could be just as effective as the ciphers themselves. Just a random thought I had today, please somebody strike me down if u think differently. ![]() A one-time pad is, so far, the only provable unbreakable cypher. But ... The problem is that no one has yet solved the problem of how to implement it. The difficulty of security is always the implementation. A single pass of Rijndael or Serpent will most likely give you a practical level of security protection for a long while. So why would you want to mess with it and try to create some hybrid scheme that you don't know if it is secure or how to implement it in a secure manner? My suggestion is just to use the existing algos in the way they were designed. |
|||
![]() |
|
AlexP 19 Jan 2008, 17:59
1) Because I'm learning, and love this kind of stuff
2) The Rijndael and Serpent key schedule's security can be mathematically proven 3)Their implementations can be proven by test vectors provided by FIPS and the Serpent designers. 4) But, pretty much because I would rather design my own algorithm (not this one, of course) than implement those created by others. I just think it's a lot funner to design and try to crack algo's. Modern complicated ones are far too crazy for me to even try solving, even the idea of "non-linear differential cryptanalysis" makes me cringe. Thanks though, if I do get it up and running should I post here? It's pretty small (You would love the template idea I have). Oh, and 5) It's actually simpler than modern ciphers, and possibly almost as secure ![]() [EDIT] Okay, the idea is pretty confusing. Right now I'm just mixing + matching ideas from other ciphers' key schedules to try and find a fast, but extremely secure one. After I get a few ideas running, I'll try to solve them (with hopefully the help of others around my school) and come up with the best one. Once I get that going, my quick + fast cipher algorithm will provide more security than any other cipher running today (I think??). I'll explain it some other time if anyone's interested... |
|||
![]() |
|
revolution 19 Jan 2008, 18:53
A1) Learning is fun
A2) What gives you this idea? A3) Implementation vectors are for the complete cypher, not just bits of it A4) Go ahead, but don't be scared of the analysis, there are powerful methods available for breaking, if you ignore them then you have a potential for an easily breakable system that you THINK is secure A5) I doubt it is more secure. It is very hard to prove it even if it really is more secure. BTW, the key schedule in all existing cyphers used today is not anything even close to a OTP. I leave this as an exercise to realise why this is true. |
|||
![]() |
|
AlexP 19 Jan 2008, 19:50
Okay, I'll play
![]() 1) Uhh yeah 2) Thought someone would actually have figured it out by now, if it's in widespread use 3) Naw, FIPS for Rijndael gives a complete breakdown of the key schedule implementation of a test vector, don't know about Serpent (which only consists (in my partial implementation) of 6 xor's 4) No-one stops learning, it might take me years to even learn some of the newer techniques being discovered. This is just a project of a teenager, not NSA ![]() 5) Ohh, I think it is pretty good. It's main purpose is to allow anyone to add code blocks that make it more secure. A template so someone can inject as much code as they want to "brute-force" a good cipher ![]() And yes, I know that having an entire algorithm relying on something as small as a 256-bit value is only secure for a few years, or at least till those guys at NSA finally understand quantum physics... |
|||
![]() |
|
revolution 19 Jan 2008, 20:10
AlexP wrote: ... something as small as a 256-bit value ... |
|||
![]() |
|
AlexP 19 Jan 2008, 20:24
1) lol you know what I mean...
2) This algo doesn't rely on a Caesar algo, it's just to prove a point. I've broken a few of those monoalphabetic substitution ciphers but that's about it, most other ones (from long ago) I can understand how to break, but for example I have never attempted a Vingere break. I get where you're going suggesting to start out small, but I've read a few books and (for the most part) understand how crazy modern ciphers work. You must think that I only perform a Caesar shift a bunch of times over based on the corresponding bytes (lol that gives only 32 different encryption methods, as long as I mod the key byte by 32), but I've added a "schedule diffusion layer" that will scramble the schedule per round. By using this with any main encryption algorithm, it essentially is just a key schedule on steroids. [EDIT] I found this tool, it has many modern and old ciphers, with graphical tutorials on them all like you wouldn't believe! Pretty fun... http://www.cryptool.com/ Didn't know anyone was that cool to make something this awesome! |
|||
![]() |
|
Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.