|
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!
|
|
|
|
|
Myself I suspect that the most important piece of information missing is which school class this is for.
|
|
|
|
|
@jschelll - sorry to disappoint. Its been many years since I left college which is probably why I'm finding it hard to write a generalized statement for the problem I'm facing!!!
|
|
|
|
|
Let me clarify my question:
x: is a discrete random variable
y: is a discrete dependent variable that follows count data model
y is a function of x.
Both x, y are both finite positive integers
Question is:
For a given p: find all x (i.e., x1, x2, ... , xi) such that
y1 + y2 + ... + yi > p
and
(y1 + y2 + ... + yi) is the smallest sum of all combinations of y's > p
|
|
|
|
|
This looks a lot like a variation on the knapsack problem[^]
That could suggest a strategy.
|
|
|
|
|
Let me clarify my response: Your question doesn't make sense, not in the original posting nor in this 'clarification: you are seeking the combinatorial optimum soultion in an infinite search space, and that is impossible to solve. You must restrict that search space to a finite set of (x,y) pairs, before the question even starts to make sense!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
