I need to create a system which agree on a key (between A and B)
without any communication between A and B. so the all algorithms such
as DH, RSA, etc are not relevant. the only way I can do it is by
obscurity.
What I am asking is - is that a common problem?
What are the way people usually solve this problem?
Can you tell us more about the obscure key generation agreement of your
system so that we can help you better?
In article <1147361212.278016.185310@j33g2000cwa.googlegroups.com>,
MajorSoul@gmail.com
>I need to create a system which agree on a key (between A and B)
>without any communication between A and B. so the all algorithms such
>as DH, RSA, etc are not relevant. the only way I can do it is by
>obscurity.
>What I am asking is - is that a common problem?
Yes -- it is common that people -want- to do something like this.
This is "The Key Distribution Problem".
>What are the way people usually solve this problem?
- they give up the requirement that there be no communication; or
- they allow security-by-obscurity; or
- they use a third party to communicate, thus technically satisfying
the constraint that there be no communication between A and B; or
- they give up the security
The "Use a third party to communicate" solution might sound sarcastic,
but it is an important element of public key cryptography [A gets B's
public key from some easily accessed place]; and of
using "certificates" to establish secure communications.
"MajorSoul@gmail.com"
>I need to create a system which agree on a key (between A and B)
>without any communication between A and B. so the all algorithms such
>as DH, RSA, etc are not relevant. the only way I can do it is by
>obscurity.
>What I am asking is - is that a common problem?
>What are the way people usually solve this problem?
It is not possible.
But if they do not communicate why do they need keys?
And if they do, use a standard technique.
Now what you may have meant is that they do communicate but that for some
reason or another you do not want them to communicate the key.
Ok,
what are the security by obscurity algorithms?
> what are the security by obscurity algorithms?
Anything you can imagine and keep secret.
Since you have two different levels of security:
1. the security of the system to keep the algorithms secret
2. the security of the algorithms themselves
It is a good idea to provide some security at level 2 in case level 1
is compromised, at least some resistance that will give you enough time
to handle the incident.
MajorSoul@gmail.com
> Ok,
> what are the security by obscurity algorithms?
Triple-ROT13.
Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain
In article <1147374646.470650.259350@i40g2000cwc.googlegroups.com>,
MajorSoul@gmail.com
>Ok,
>what are the security by obscurity algorithms?
Please quote context. Please see here for information on how to
do so from Google Groups: http://cfaj.freeshell.org/google/
There are many possibilities. For example, the security could be
the UDP-based equivilent of "frequency hopping".
I dont see how level 2 can help in case level 1 is compromised. If the
algorithm is no longer a secret, everything is lost. It is all a matter
of definitions where does the definition of the algorithm begin and
where it ends.
What I mean to say is: you can think of AES as a known algorithm and
the key is a secret (secret, obscurity - same thing), OR, you can think
of "AES + a specific secret KEY" as the algorithm, which is obscurity.
It is the same thing once level 1 is broken - the secret is revealed.
You are right, they do communicate, but only after the key is agreed
upon.
What are the standard techniques?
DH? it does not help cause of man in the middle attack.
so we have too more possibilities:
certificates - which mean you have to have a private key. if generating
an RSA is too heavy for you, you must pre-load, and it is the
equivalent to an obscurity algorithm.
symmetric authentication - how to do key agreement?
"MajorSoul@gmail.com"
>I dont see how level 2 can help in case level 1 is compromised. If the
>algorithm is no longer a secret, everything is lost. It is all a matter
>of definitions where does the definition of the algorithm begin and
>where it ends.
>What I mean to say is: you can think of AES as a known algorithm and
>the key is a secret (secret, obscurity - same thing), OR, you can think
>of "AES + a specific secret KEY" as the algorithm, which is obscurity.
>It is the same thing once level 1 is broken - the secret is revealed.
The difference is in the probablility of the secret being revealed. In the
case of the algorithm, thousands or millions use the same one, and it is
there waiting to be "revealed" even when no messages are sent or received.
It sits on the computer. of all those millions. If that secret is revealed
for at least one of those people it is revealed for all. This is the
equivalent of the theft of an Enigma rotor machine in the war. One stolen,
all revealed. In the case of the password each of those users (should ) use
a different one. It is much easier to keep secret. Ie, there is a clear
demarkation of both relative ease of secrecy and cost of loss thereof.
The algorithm by design is also stored in cleartext-- that is what the
computer needs to run it. Thus the theft of one laptop and the game is
over.
Could you design and impliment an algorithm which was safefrom
discovery. Probably. but it is harder than for the key simply because it is
bigger.
"MajorSoul@gmail.com"
news:1147361212.278016.185310@j33g2000cwa.googlegroups.com:
> I need to create a system which agree on a key (between A and B)
> without any communication between A and B. so the all algorithms
such
> as DH, RSA, etc are not relevant. the only way I can do it is by
> obscurity.
>
> What I am asking is - is that a common problem?
> What are the way people usually solve this problem?
>
Your question is poorly worded/informed, which is why you havn't
gotten much help, but fair and secure key exchange is one of the
biggest problems in cyrptosystem design and implementation.
There are many solutions to the problem. Back in WWII they used to
use code books to do this. Try a modern version.
Generate two identitical DVD's full of secure random numbers, secure
one DVD at each location. Before you wish to send any messages,
agree with the remote about a protocol for choosing a random sequence
off the DVD. Now use the random numbers you have selected as a key
for a secure cryptosystem or one time pad.
In reality all of these so called key exchange restrictions can
usually be lifted by proper planning. If you truly had an
insurmountable key exchange problem, such as national security
secrets, etc., you would already know the answer to your question.
Therefore your question is invalid because you asked it.
In article
SOiL
>"MajorSoul@gmail.com"
>news:1147361212.278016.185310@j33g2000cwa.googlegroups.com:
>> I need to create a system which agree on a key (between A and B)
>> without any communication between A and B.
>Your question is poorly worded/informed, which is why you havn't
>gotten much help,
Was the amount of help offered somehow inappropriate? Was there a
need for a large number of people to say, "You can't really do that" ?
>but fair and secure key exchange is one of the
>biggest problems in cyrptosystem design and implementation.
>There are many solutions to the problem. Back in WWII they used to
>use code books to do this. Try a modern version.
>Generate two identitical DVD's full of secure random numbers, secure
>one DVD at each location.
If one of the ends sends the DVD directly to the other, then we
have a violation of the constraint that there cannot be any a priori
communication between the two ends. If the sending of the DVD is
via a third party, then you have the solution I posted early on
in the thread, to use a third party for communications (which can
include crypto certificates for example.)
>In reality all of these so called key exchange restrictions can
>usually be lifted by proper planning. If you truly had an
>insurmountable key exchange problem, such as national security
>secrets, etc., you would already know the answer to your question.
My guess was that the original poster was thinking of something like
Skype, or a P2P program, or possibly something like a secure payment
system, and wanted a method by which a relatively random person could
securely transfer information to another person without having to have
set up a key before-hand. However, I do not know why the OP ruled out
the standard session-key exchange methods.
Which leads me back to the original point: the OP would likely have
received more help if the OP had clarified the problem in light of
other people's responses.