|
How many keys are you using? (I mean public/private).
How you exchange keys?
There is default values for key size?
Did you run some performance tests on real life data?
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
Daniel Mullarkey wrote: How much is this encryption algorithm potentially worth if I patent it?
Not much, since there are already high quality encryption methods available at no cost.
|
|
|
|
|
Well, to address both replies, the core function headers look something like this:
Public Function Encode(ByVal UnencodedValue As Integer, ByVal KeyValue As Integer, ByVal MinimumValue As Integer, ByVal MaximumValue As Integer) As Integer
Public Function Decode(ByVal EncodedValue As Integer, ByVal KeyValue As Integer, ByVal MinimumValue As Integer, ByVal MaximumValue As Integer) As Integer
Keep in mind that UnencodedValue and EncodedValue can range anywhere from MinimumValue to MaximumValue and that the KeyValue can range anywhere from MinimumValue + 2 to MaximumValue.
|
|
|
|
|
Encryption is not only (and not mainly) about hide your data behind numbers. It can be smart but that's not nearly enough...You have to think about the data exchange between the side encrypting and the other that decrypting the data. For every encryption has helpers - these are the keys - and those helpers are have to pass (or be presented) on both side. You method signatures are telling nothing about that - just from this we can't tell nothing about, how your encryption is good. It also tells nothing about it speed of execution...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
modified 23-Mar-14 10:49am.
|
|
|
|
|
Well, I can say that the core methods involve 10 lines of code, one with a conditional (if...then) recursion that at best only occurs once per original use and the rest involves conditional (if...then) mathematics at three levels, thereby making it very quick and very fast. Besides, ever heard of lossless compression? Well, I might as well have created perpetual lossless, key-based, encryption. Keep in mind that the encryption algorithm is symmetrical, so the very idea of having public keys would be a bad idea. The core of my encryption algorithm is essentially a block cipher in which the unencrypted value does not grow or shrink in size when encrypted. Also, keep in mind that it can not only encrypt bulk data, but it can also use bulk keys. And one day I will show that I can deliver on the goods. I just have to find a way to afford to pay LegalZoom $1,000 to patent it.
"In cryptography, a block cipher is a deterministic algorithm operating on fixed-length groups of bits, called blocks, with an unvarying transformation that is specified by a symmetric key. Block ciphers are important elementary components in the design of many cryptographic protocols, and are widely used to implement encryption of bulk data."
--Quoted from Wikipedia from Block cipher
|
|
|
|
|
I'm not really interested in the details of your code, what I'm trying to tell you that your core methods are just the core...It's a very good thing that it performs well, however the recursion is always turn a red light on with me...That kind of methods need intensive test with different kind of data...
Daniel Mullarkey wrote: encryption algorithm is symmetrical
According your previous post - with the method signatures - it's true only if you have key, min and max values...So still you have to consider how do you share that info between the parties...
So bfore you spend that $1000, try to fill all the gaps (and may be more that I listed). You may look into existing protocols for info how they build...
http://en.wikipedia.org/wiki/Cryptographic_protocol[^]
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
modified 23-Mar-14 11:04am.
|
|
|
|
|
All encryption is lossless? You have to be able to undo it back to the original :P
|
|
|
|
|
I suspect you really need to study the principles of encryption. Any encryption system worth its salt should be language neutral, and able to handle any stream of bytes rather than just integers.
|
|
|
|
|
Bytes can be transformed into integers easily enough using any modern programming language and since I have already succeeded with strings and characters, bytes are on their way. :8)
|
|
|
|
|
Daniel Mullarkey wrote: Bytes can be transformed into integers easily enough using any modern programming language
And how do you decide how many bytes to make up each integer? There is no correspondence between the two types. In reality any encryption/decryption system works purely on a stream of bytes, the actual values of individual groups has no relevance.
|
|
|
|
|
Would you believe that I used conversion type functions?
|
|
|
|
|
I would believe anything, but what does that have to do with producing an efficient and valid encryption algorithm?
|
|
|
|
|
Nothing, in and of itself. What makes my encryption algorithm unique is that unlike other encryption algorithms, the set of all unencrypted values, encrypted values, and key values, are electronically indistinguishable from one another, while the each unencrypted value its corresponding encrypted value are still uniquely different from one another.
modified 5-Apr-14 10:21am.
|
|
|
|
|
So you keep telling us, but that proves nothing. Your algorithm needs to be tested to destruction by experts in the field, before anyone is going to pay you any money for it.
|
|
|
|
|
That point I will concede. Nonetheless, I was planning on licensing it out, rather than selling the patent wholesale.
|
|
|
|
|
Daniel Mullarkey wrote: I was planning on licensing it out
Well you still have the same problem. Who do you think is going to want to licence an encryption system without any evidence of its efficacy?
|
|
|
|
|
It's fine to use int as a shortcode for 'group of 4 bytes' imo, that's what int means in pretty much every modern environment.
|
|
|
|
|
I understand that, I'm not sure that OP does.
|
|
|
|
|
I'd have to agree with the conclusions here and on Google[^] - the description is not enough to evaluate the value of your algorithm, and proprietary closed-source encryption algorithms are never a good idea. Since there are perfectly valid free and open-source algorithms available which have undergone years of intensive analysis, the chances of getting anyone to switch to your new, unproven algorithm are practically zero, even if you gave it away.
Daniel Mullarkey wrote: The algorithm uses carefully calculated mathematics to give the appearance of gibberish until it is decoded with the proper key or combination of keys.
As Arne Vajhøj said in your Google thread[^], that's practically the definition of encryption.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Most or perhaps all of your description is exactly what all encryption algorithms not only do but must do to be encryption algorithms in the first place.
Other than that if you cannot patent your encryption algorithm then it is worth nothing. Or at least worth nothing more than whatever snake oil your sales people can get from it.
http://www.networkworld.com/columnists/2001/0827schwartau.html[^]
If it can be patented then do so with a small market release and then use sales from that to patent/protect it in other places. Or just sell it to someone who already does it.
|
|
|
|
|
All it can get you is street cred; you won't make any money from it directly, but it could get you your foot in the door at some large corporation.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
A closed source encryption algorithm is worth pretty much nothing, because there's no way to evaluate how strong it is. So there's no way we can answer this question without seeing the code, which obviously you can't share because it would invalidate a patent application if it were in the public domain.
An encryption algorithm with no linkage between blocks is relatively weak, because an attacker can take blocks in isolation and generate parts of the key, particularly if he knows what some of the content is. If your key is long enough then it becomes a one-time pad which is unbreakable, but you've just deferred the problem to how to exchange keys securely.
If your algorithm is weaker than DES then I doubt it's worth anything. However, having your name on a patent could give you some industry kudos and make it easier to get a good job or consultancy work.
|
|
|
|
|
In short, it is designed to compete with PGP. Even the keys themselves can be encrypted with my algorithm, by using the same key block or another key, thereby making it more difficult to intercept a key.
|
|
|
|
|
I wonder what optimization algorithm should be used for such a problem:
x: independent variable
y: dependent variable
For y = f(x), find all x such that:
sum of y is > p where p is a positive integer
sum of y is the minimum of all sums that are greater than p
|
|
|
|
|
There is important information missing:
1. what types are x and y?
2. what are valid ranges for x and y?
3. what do you mean by "sum of y"? For any given x, there is only one y - what is it that you sum up?
4. what are the properties of f()? E. g. is it monotonous, continuous, continuously differentiable? Can you even give an exact definition? Is it even a function? You do not state as much!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
