# obscurity for key generation

#### Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

•  Subject
• Author
• Posted on
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?

## Re: obscurity for key generation

Can you tell us more about the obscure key generation agreement of your

## Re: obscurity for key generation

Yes -- it is common that people -want- to do something like this.

This is "The Key Distribution 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.

## Re: obscurity for key generation

Ok,
what are the security by obscurity algorithms?

## Re: obscurity for key generation

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.

## Re: obscurity for key generation

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.

## Re: obscurity for key generation

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.

## Re: obscurity for key generation

Triple-ROT13.

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

## Re: obscurity for key generation

There are many possibilities. For example, the security could be
the UDP-based equivilent of "frequency hopping".

## Re: obscurity for key generation

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.

## Re: obscurity for key generation

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?

## Re: obscurity for key generation

such

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

## Re: obscurity for key generation

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" ?

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.)

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.