|
I answered your original question about three points on a line;
I dont see how a password gets translated in one or more points;
and I dont believe your password story makes any sense
|
|
|
|
|
It makes sense it just might be my ability to explain it.
1) take a value (12)
2) take a some graph paper and on the draw a dot on 12x
3) draw a line of any slope you want
4) then pick any two points along the line you just drew vola
thats what im trying to do.
And again this could jsut go back to me not understanding something right infront of me but it appears to do these steps in some what reverse order
you make two points then run find what value that runs through which doesnt work becuase the value of x is what is important
I have been reading through the old post in this tread and it shouldnt be 3 points of freedom it should be 2 or mabey 1
if i know that one point is X=varable,y=0 (call it pnt0
couldnt i make a random point then draw a line
from that random point to Pnt0
then expand the line a little and get a diffrent value?
just thought of that but im not sure how to write it up.
thanks
|
|
|
|
|
Here is my new attempt at the code
Random random = new Random();
Point pnt1 = new Point(random.Next(1,1000) ,random.Next(1000));
Point pnt2 = new Point(Convert.ToInt16(textBox7.Text),0);
Point pnt3 = new Point(1,1);
float slope;
slope = (pnt2.Y - pnt1.Y) / (pnt2.X - pnt1.X);
pnt3.X = pnt3.X * (random.Next(1000) * slope);
pnt3.Y = pnt3.Y * (random.Next(1000) * slope);
|
|
|
|
|
Random random = new Random();
Point pnt1 = new Point(random.Next(10000) ,random.Next(10000));
Point pnt2 = new Point(Convert.ToInt16(textBox7.Text),0);
Point pnt3 = new Point(1,1);
int slope;
slope = (pnt2.Y - pnt1.Y) / (pnt2.X - pnt1.X);
int t = random.Next();
pnt3.X = t * slope + pnt2.X;
pnt3.Y = t * slope + pnt2.Y;
|
|
|
|
|
Since your password is based on geometry and simple graphing, and you, the user of this program, KNOW the entire password already, why don't you just randomly generate two points (using large integers) and draw a line through them. From that line, pick any two points and use it as each half of the password.
You could even use the(x,y) form to create a password like xy where if (x,y) was (1234, 2312) the password half would be 12342312.
This way you don't even have to generate so many lines in the first place. Of course, your password idea has many flaws, most notably the fact that any number-only password can be brute-forced quite easily.
I personally think you need a more secure password system, but the idea is neat Kudos.
|
|
|
|
|
1) the intent is not for it to be numeric only the converting of passwords to a numeric form is another process that doesn't really need to be in the math forum
2) of course some one needs to know the original password thats how you encrypt it
one seneario would be for a Manager of an it department to give one set of keys to one department and one set to another department for lets say the root of a server.
now neither side can do work on the server unless both departments are present.
3) the xy idea would work if it was numeric only. however as stated above its not also i like the idea of y=0 as a check sum
4) the other idea of this project is that it can be "undone" by simple math on paper. no computer is required in case of a computer failure the points are simple enogh to be written down on a piece of paper and undone
this can for the most part not be said about keys for other encryption.
|
|
|
|
|
Michael Sadlon wrote: You could even use the(x,y) form to create a password like xy where if (x,y) was (1234, 2312) the password half would be 12342312.
one other thing to note
this isn't splinting the password securely
if i gave out the first half of a password to someone and it wass "pass"
they could quickly guess what the rest of the password was and even if it wasnt a logical password like "3@!DE34s" they would still be halfway to brute forcing it.
8 to 4 char is a big difference in time.
the entire point of this is that neither side can guess because there are infinite possibility of what the other sides point may be.
|
|
|
|
|
I think this thread is a lot of effort for very dubious security benefits. I think that there are much simpler methods of achieving what you want, e.g.
1. Take your password and map it to a 256 bit number A (longer if you want to allow more characters in your password, shorter if you need less). Do this in some reversible way, e.g. encryption
2. Generate a 256 bit random number B.
3. Give A^B to one user and B to the other.
Neither user can decode the password, but together, (A^B)^B = A which can be decoded to the original password.
This can be easily extended to needing three users, generate an additional random number C, the keys are (A^B)^C, B, C and so on.
There are almost certainly recognised methods of achieving this that have been subjected to significant scrutiny.
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
yes that will work
however
just because something is hard does not mean it should not be done. This is more of a training exercise for me. than an actually program that i have to prove is secure.
and again if you feel like reversing that with out the aid of a computer be my guest
on of my requirements is that this code is human decipherable. where it could be done with nothing but paper.
|
|
|
|
|
I wasn't trying to give you a hard time, but to be constructive.
crash893 wrote: just because something is hard does not mean it should not be done
I agree - but it is still not clear to me that the individual parts of the password wouldn't be amenable to some sort of dictionary attack for example.
crash893 wrote: than an actually program that i have to prove is secure
I thought in an earlier post you were going to use this to secure something - in which case you may need to know something about the security.
crash893 wrote: and again if you feel like reversing that with out the aid of a computer be my guest
The issue here is that someone trying to hack the system will almost certainly use a computer.
Anyway, good luck with it, I hope you get it working.
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
no worries thanks for your input
|
|
|
|
|
|
Do you want to reform geometry because of True Type fonts handling is a complex task, don't you?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
The Grand Negus wrote: Real math is a highly-developed but obtuse system that we're trying to apply, with partial and scattered success, in a discrete universe.
Actually math is not only higly-developed, it's great!
The Grand Negus wrote: The point is that a tool should make the accomplishment of a job easier, not harder
Math is not a tool is a science. You can only say it is one of the best Tool we have to make a bit of light into the obscure Universe.
Anyway, good luck and enjoy yourself with you workplan.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Thanks
Anyway, Math it's not guilty if the Graphic Library is buggy!
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
The Grand Negus wrote: But that's my point. The graphic library isn't buggy
Yes, it is.
The Grand Negus wrote: it's just having trouble deciding which pixels belong to a line
This is task showing library misbehaviour (note that it's a library task, not a math one).
The Grand Negus wrote: by definition, has no width
This is the mathematical side of the argument, where all goes fine!
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Many different kinds of geometry already exist, providing your 'geometric rules' are applied consistently to a closed data set (for example the set of all integers) then I guess you could 'create' any kind of geometry you wanted.
I'm not sure I agree with you on the argument behind this - conventional exists as a way of describing the real world and it works very well. It 'fails' when applied to fonts (for example) because of the restrictions applied to the data set (Real numbers) by the discrete device used to display the fonts and not because the geometry is wrong!
As a mathematician I'd be glad to look at this for you - providing we can agree on payment terms 
|
|
|
|
|
The Grand Negus wrote: Works very well" only in very limited circumstances. The formula for the volume of a cylinder, for example, is simple enough; but put a few bumps on the thing and there is no comprehensible formula to describe it. Equations are great for schoolbook cylinders, but they're no good for tree trunks. The universe is an algorithm, not an equation.
It works very well not in limited circumstances but for the circumstances for which it was designed ie to describe the real world in mathematical terms. All advances in mathematics have taken us a step (a very small step) nearer to describing the world fully. I would suggest that our current understanding of mathematics barely scratches the surface!
As for your cylindrical example - the formula for the volume of a cylinder is precisely that, if you want to find the volume of a cylinder with bumps on it or a tree trunk then you would need a formula for that - but first and more importantly you need a method of describing the object, this is probably the most difficult part! Until you can define precisely the nature of the data set 'tree trunks' you can't possibly hope to find the formula to convert a member of the data set 'tree trunks' into a member of the data set 'volume'. The same of course applies to any 'real world' object, and by that I mean tree, house, worm car etc and not the mathematical real world, real numbers integers, cylinders, squares etc.
|
|
|
|
|
|
(1) Yes I understand
(2) As a mathematical curiosity I might look at the possiblilty of an integer geometry in my spare time
|
|
|
|
|
|
I think that any work in this area is doomed to irrelevance unless you take perception into account, it appears to me that this is where much of the current work is happening. To explain what I mean, take a block of pixels and look at all possible arrangements of colours, some of these will be perceived to contain recognizable patterns, such as lines, the letter 'A' etc. The boundaries of these sets will be fuzzy (like the graphics). The goal of any improved rendering technique should be to achieve the highest perception scores from users, and not concentrate simply on algorithmic details of rendering on a pixellated screen.
The Grand Negus wrote: The goal is to show that by starting with shapes and operations native to a discrete coordinate system, computer graphics can be both conceptually simpler and more easily implemented than with the traditional mathematical approach.
Whilst admirable goals from a programming perspective, the bigger picture surely must be perception dominated.
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
The Grand Negus wrote: where the formulas are minimal data structures for describing those shapes (in our Plain English programming language); and where the algorithms for drawing, filling, translating, rotating, and scaling are also presented in Plain English.
Defining a whole new geometry in so called 'plain english' (programming language or not) just isn't going to be feasible. The geometry must be defined in mathematical terms either using existing notation or creating new notation (mathematicians are very fond of this!). The reason for this is obvious, y=mx+c is easier to understand (for me anyway) than "the value along the y axis is equal to the value along the x axis multplied by another value m representing the slope of the line added to a constant which is the y value where the line crosses the y axis"
Once defined in the correct notation it may then be translated into the plain english version but to be honest I would have to wonder why when in C (ugly or not) we can write y=m*X+c; and be finished.
|
|
|
|
|
|
Well I've never been called lukewarm before! I have a problem with the 'plain english' its your 'baby' I don't know enough about it to know what it can do - if its that good why isn't everyone using it? I haven't made any deliberate attempt to give you any grief - I'm passionate enough about my work to question everything (EVERYTHING) I don't understand - asking questions is how research is done, I don't care if the questions are uncomfortable or don't agree with your way of thinking. You might be right I don't know - but I have to ask the questions!!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
