Minimize key size for sending only 10 messages
am 18.04.2006 10:00:03 von Ulf Reiman
Hi
If I want to have a secure system, as always.
Moreover, want to minimize the key length in the nodes, for sending
data over a wireless network.
The keys will be used to sent only 10 messages, is there any info about
suitably algorithm, and keysize?
Regards
Ulf Reiman
Re: Minimize key size for sending only 10 messages
am 18.04.2006 15:43:50 von roberson
In article <1145347203.015338.88700@z34g2000cwc.googlegroups.com>,
Ulf Reiman wrote:
>If I want to have a secure system, as always.
>Moreover, want to minimize the key length in the nodes, for sending
>data over a wireless network.
>The keys will be used to sent only 10 messages, is there any info about
>suitably algorithm, and keysize?
The choice of keysize and encryption algorithm is a tradeoff between
the computation required and the security level you need. You have
not defined the security level you need, so we can't really make
any recommendation.
There really isn't any such thing as a "secure system": all
there are are systems that are more difficult to get access to.
You could build a 10 metre thick and 40 metre high wall around your
house, and that might keep out casual intruders, but it would not
stop someone who brought in a crane with wrecking ball.
Re: Minimize key size for sending only 10 messages
am 19.04.2006 21:00:03 von roberson
In article <1145428277.176391.310960@e56g2000cwe.googlegroups.com>,
Ulf Reiman wrote:
>I want the security level to be "Compuational security" for the keysize
>and algorithm(s)
Please quote context. Please see here for information on how to
do so from Google Groups: http://cfaj.freeshell.org/google/
I must not be understanding what you mean by "Computational security"
in this matter. If you mean that you want the security to be determined
only by the computational effort theoretically required to crack the
encryption, then you will not be able to achieve your goal: there
will always be possibilities such as keyloggers, spycams, Van Eck
phreaking, analysis of the time lags of the timing of your key presses,
and other factors that I'm sure I haven't thought of.
Even if you are willing to overlook the "out of band" mechanisms for
obtaining the key, I do not see how saying that you want "computational
security" is relevant to the problem. If I were to give you an
algorithm that used a two-bit key, and was trivially attacked, that
would still meet your requirement of "computational security for the keysize
and algorithm".
You have asked us about the minimum key size for sending 10 messages
securely, but you have not defined for us what level of computational
effort is "difficult enough" for your requirements. If you are just
trying to obscure your vegetable-shopping list on the principle that
it isn't anyone else's business, then the security requirements would
be quite different than if you are doing Electronic Funds Transfer
up to the fourty-two million Euro level.
I am also unclear on your point about it being only 10 messages to
be transfered. Do you mean that you have a one-time need to send
10 packets, and want to do so securely? Do you mean that you have
groups of 10 packets, but each group will use a different session key?
If so, then how are you going to securely distribute the session keys?
Does your situation require the equivilent of IKE Phase 1 and Phase 2,
with the session key being negotiated within an encryption formed from
a preshared key (or certificate)? If so then when you are asking for
algorithms you should specify this, as there are different key negotiation
algorithms with different overheads.
Is your point about 10 messages that there will only be a relatively
short cryptographic text to be analyzed, rather than a large text?
Depending on how you do things, that could -decrease- security, because
your groups of 10 packets will likely have a lot of structure that
could be cross-analyzed. As you have not given us much to work with,
we also have to wonder how you have protected yourself against
replay attacks, and against provocations of known-plaintext attacks?
Have you considered timing differential attacks for the situation where
someone sends you groups of packets encrypted with known keys (e.g., if
you decrypt the first packet according to the key you know and find
that it has nonsense contents [because it was encrypted with a
different key], do you immediately NAK or do you wait until all the
packets have been received? If you NAK immediately then if the key were
somehow to become known, it would be possible to analyze the structure
of the messages according to how long you took to refuse bad
messages...
There is more to security than just asking someone to tell you an
algorithm and its relative key strength, -particularily- when you
send short structured messages and have key distribution issues to
worry about...