What about the possibility of forging a key from whatever lock happens to be locking the box. It is possible to obtain the pattern to recreate the key that unlocks a standard lock. This possibility makes it extremely difficult to guarantee the security of the object.
-Ray.
Originally posted by rgoudieThat's the second of four.
What about the possibility of forging a key from whatever lock happens to be locking the box. It is possible to obtain the pattern to recreate the key that unlocks a standard lock. This possibility makes it extremely difficult to guarantee the security of the object.
-Ray.
For every security feature that you add and put your trust in,
that's one more weakness that can be exploited by the enemy,
because realistically, no practical security method is flawless.
So when you have two locks instead of one, either of which
you will trust, you are increasing the enemy's chances.
There are two more advantages I have in mind.
Dr. Cribs
Originally posted by fearlessleaderIt's not clear that there is an electronic analogy to the proposed
the three send method seems to work, because there is no reason you can not have multipul encriptions on a message
2-lock method.
Let M be the message, A be the first lock, B the second lock,
A' be the first key, and B' the second key.
So we start with M.
Lock it: A(M)
Lock it again: B(A(M))
Now ultimately we need B'(A'(B(A(M)))) = M
So, A'(B(A(M))) must equal B(M).
So when the sender gets the box back and goes to unlock it,
he needs a transformation A'(B(A(M))) that yields B(M).
I claim he cannot do this without knowing B. But if he
does know B, then B is not really a lock in the first place.
So I don't really see how this inter-tangling of locks is
can be implemented.
Obvioulsy multiple arbitrary encryptions can exist, but only only
when applied in a LIFO, layered manner. To do otherwise is
to expect deadlock.
Dr. Cribs
P.S. If you would refute this argument by saying that both
parties could share the knowledge of any of A, B, A', B', then
that violates by analogy the constraint that the parties may
not exchange keys or open locks.
P.P.S. In fact, if you do allow the sharing of information about
some of A, B, A', or B', then the above method is not only
feasible but essentially the same as public key encryption.
That is why I raised hell when rgoudie said you couldn't
share keys or open locks, becasue you need to share some
for the above method to work in the electronic realm.
(The sequence essentially becomes A'(B'(B(A(M)))) = M.
But because it is the first party who applies B', that is analogous
to sharing keys, which the problem prohibits but the real-world
solution requires.)
- Joined
- 26 Apr 03
- Moves
- 26771
Originally posted by CribsI don't know the mathematical term, but the B and A operations could be like multiplication, then you could do the divisions in either order to restore the original message.
It's not clear that there is an electronic analogy to the proposed
2-lock method.
Let M be the message, A be the first lock, B the second lock,
A' be the first key, and B' the second key.
So we start with M.
Lock it: A(M)
Lock it again: B(A(M))
Now ultimately we need B'(A'(B(A(M)))) = M
So, A'(B(A(M))) must equal B(M).
So when the send ...[text shortened]... analogous
to sharing keys, which the problem prohibits but the real-world
solution requires.)
Originally posted by iamatigerHere's the problem with that. The constraints
I don't know the mathematical term, but the B and A operations could be like multiplication, then you could do the divisions in either order to restore the original message.
of the problem dictate that the parties can't lock
or unlock each other's locks. This essentially means
that I, as the first party, have to construct my
A/A' pair such that A'(B(A(M))) = B(M) for any arbitrary
B that the second party constructs.
There is the trivial solution A(x) = x and A'(x) = x.
But this represents the case where you are not really
doing any locking at all. There are probably a whole
class of degenerate solutions like this, but they are
all too trivial to really be called "locks," in the sense
that once you have A(M), the only non-trivial way to
retrieve M should be to apply A'(A(M)). PGP's implementation
is based on prime factorizations that are trivial in one
direction but too computationally intensive to reverse
in a reasonable amount of time.
Sure, if the parties cooperated to construct their
functions, as you describe, then it could be done.
But the spirit of the problem constraints, and the
solution that we are analyzing, forbid this.
Dr. Cribs
Think I've sussed it:
1. A sends B the unlocked padlock "AA" in the open box.
2. B returns to A the unlocked padlock "BB" in the same box locked with padlock AA.
3. A opens the padlock AA with his key AAA and gets the open padlock BB from the box.
4. A then puts the item in the box, locks it with padlock BB and sends it to B.
5. B unlocks the padlock BB with his key BBB and... bingo, he has the item!
6. At the end of the exchanges, A has padlock AA and key AAA, whilst B has padlock BB and key BBB and the item. Correct?
- Joined
- 26 Apr 03
- Moves
- 26771
Originally posted by CribsBased on the idea of prime factorisation being hard that you mention:
Here's the problem with that. The constraints
of the problem dictate that the parties can't lock
or unlock each other's locks. This essentially means
that I, as the first party, have to construct my
A/A' pair such that A'(B(A(M))) = B(M) for any arbitrary
B that the second party constructs.
There is the trivial solution A(x) = x and A'(x) = ...[text shortened]... of the problem constraints, and the
solution that we are analyzing, forbid this.
Dr. Cribs
If X is a massive prime number known only to me Y is a massive prime number known only to my friend, and the secret number we want to encode is N, Then I can do N -> XN - which no-one else can decode easily, my friend can do XN - > YXN. I can divide by X to do YXN -> YN, and my friend can divide by Y to do YN-> N
Now the numbers X and Y are the keys, XN and YN are the box with one lock on, and YXN is the doubly locked box - what's wrong with that?
Originally posted by iamatigerThe only problem is that you and your friend are cooperating in the
what's wrong with that?
design of such locks. In my view this violates the spirit
of the problem that open locks and keys cannot be shared.
The problem allows only closed locks to be shared, which
by analogy, I take to mean only "black-box" locking functions
whose workings are completely unknown to the other party.
In other words, you could do your part, but the spirit of the
problem constraints disallow you to expect your friend to
cooperate in, or even know about, the proposed implementation.
Think of it this way. Suppose instead of keylocks, we are using
combination locks. I think the analogy is clear that the combination
plays the same role as the key. The problem would not allow the
parties to tell each other their combinations. I think my analysis
about limiting each party to know about only their own locking functions
is equally valid, for the same reason that the parties could not
share combinations.
But again, just to reiterate, take away the constraints that forbid
the exchange of open locks and keys, and your proposed solution
is great.
Dr. Cribs
- Joined
- 26 Apr 03
- Moves
- 26771
Originally posted by Cribs
The problem allows only closed locks to be shared, which
by analogy, I take to mean only "black-box" locking functions
whose workings are completely unknown to the other party.
The physical things we know about locks and keys imply that the locks can be taken off in a different order to that which they are put on. If we are trying to find a numeric analogue of this phyisical problem, then we have to retain that crucial behaviour.
Think of it this way. Suppose instead of keylocks, we are using
combination locks. I think the analogy is clear that the combination
plays the same role as the key. The problem would not allow the
parties to tell each other their combinations. I think my analysis
about limiting each party to know about only their own locking functions
is equally valid, for the same reason that the parties could not
share combinations.
Combination locks will work fine in both our solutions - imagine the large prime multiplier in my numerical analogue is the combination in your physical system.
But again, just to reiterate, take away the constraints that forbid
the exchange of open locks and keys, and your proposed solution
is great.
In what sense am I exchanging a key (which is the large prime number) or an open lock? I am merely exchanging some information about which locks will fit the box I have.
Originally posted by iamatigerI think we are just short of seeing eye to eye on the
In what sense am I exchanging a key (which is the large prime number) or an open lock? I am merely exchanging some information about which locks will fit the box I have.
numerical analogy.
In your view, the particular Y that is chosen is analogous
to the second party's key.
In my view, the first party's knowledge that the second party is
going to multiply by some prime Y is analogous to the second
party's open lock.
I don't know whether one of our views is more appropriate or not.
The benefit of yours is that there is a more direct analogy between
the components. But in mine, I think there is a more direct analogy
between the locking and unlocking processes, because the first
party can only do the unlocking confidently if he knows something
about the second party's lock (whereas in the problem solution,
he simply knows that there is a lock, and nothing further about it.)
Dr. Cribs
P.S. Perhaps this question will help us see eye to eye. In your
analogy, what represents an open lock? There must be something
because the problem statement forbids its exchange. In my view,
the open lock is the "I'm going to multiple by a prime" expectation.
And thus by analogy, this exchange should be forbidden; i.e., the second
party can't share this information with the first.
- Joined
- 26 Apr 03
- Moves
- 26771
Originally posted by CribsMy view is that there is no "open lock" in my analogy. It can therefore never be exchanged. I don't think this changes the validity of the anology because open locks are not crucial to the original problem. (There do have an analogy in a solution using public/private keys - they are essentally the public keys, and hence the constraint that they cannot be exchanged effectively rules out a public/private key solution)
I think we are just short of seeing eye to eye on the
numerical analogy.
In your view, the particular Y that is chosen is analogous
to the second party's key.
In my view, the first party's knowledge that the second party is
going to multiply by some prime Y is analogous to the second
party's open lock.
I don't know whether one of our views is ...[text shortened]... hange should be forbidden; i.e., the second
party can't share this information with the first.
Originally posted by howardgeeno exanging of unsecure unlocked locks.
Think I've sussed it:
1. A sends B the unlocked padlock "AA" in the open box.
2. B returns to A the unlocked padlock "BB" in the same box locked with padlock AA.
3. A opens the padlock AA with his key AAA and gets the open padlock BB from the box.
4. A then puts the item in the box, locks it with padlock BB and sends it to B.
5. B unlocks t ...[text shortened]... nges, A has padlock AA and key AAA, whilst B has padlock BB and key BBB and the item. Correct?
First, a disclaimer: i dont know a damned thing about computer security.
it seems to me that there is no reason to restrain one's self to prime numbers. any computer message is essentaly a really big number, and the lock/key (the key is just knoledg of the lock) is just another really big number. X is the message. Y is the first lock. Z is the second lock. to apply lock Y, one just multiplies X and Y. to apply lock Z, you multiply XY by Z. by the basic laws of algibra, one can divide by either lock first, then the second, and you will still get a perfectly intact X.