Cryptography-Digest Digest #535, Volume #14 Wed, 6 Jun 01 12:13:01 EDT
Contents:
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes
(Bob Silverman)
Re: Def'n of bijection (Tim Tyler)
Re: Definition of 'key' (Bob Silverman)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Brute-forcing RC4 (S Degen)
Re: fast CTR like ciphers? (Tim Tyler)
Re: fast CTR like ciphers? (Volker Hetzer)
Factoring via BBS cycle length (Tom St Denis)
Re: Brute-forcing RC4 (Ichinin)
Re: Def'n of bijection (Mok-Kong Shen)
Re: fast CTR like ciphers? (Tim Tyler)
Re: Medical data confidentiality on network comms (Barry Margolin)
Re: Def'n of bijection ("Douglas A. Gwyn")
Re: Def'n of bijection ("Douglas A. Gwyn")
Re: Def'n of bijection ("Douglas A. Gwyn")
Re: Def'n of bijection ("Douglas A. Gwyn")
Re: function notation (injection, bijection, etc..) one last time ("Robert J.
Kolker")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
Re: Medical data confidentiality on network comms (Mok-Kong Shen)
Re: Def'n of bijection ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 6 Jun 2001 14:07:27 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <3B1E3235.89950379@t-
online.de>:
>
>
>"SCOTT19U.ZIP_GUY" wrote:
>>
>[snip]
>> If the defination is true. Then for the set of message to be
>> encrypted. The key has to be as long as the longest message.
>> If a shorter cipher text is sent then you have learned that the
>> longest message was not sent. That is information about secret
>> message. It violates Shanons defination.
>
>I have a dumb question: If I have a short message to
>send and the key is longer, what should I do? Need I
>pad it to the length of the key and send that longer
>stuff? Thanks.
>
>M. K. Shen
>
Its not a dumb question. Most of the time you don't
need perfect security. But if you have a wide mix
of messages I would try to pad in a bijective way to
some minimum size. However being secure and perfectly
secure are two different things. ANd in general if you
have a short message less than the key it most likely
can't be solved for. All that may be required for safety
is that many keys lead to a false solution. All perdect
security really does is give "zero information". But just
like an OTP is not practical in most cases. Sending long
encrypted messages is not pratical either. It is just
somthing to think about. For example if your ecnrypting
an an anwser to a yes no question some one asked. And it
is known you will answer "yes" or "no" it would be foolish
to use somthing as weak as AES in CTR mode where file length
does not change. Since attacker would know "XQ" is no
while "RTG" is yes.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (Bob Silverman)
Subject: Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large
Primes
Date: 6 Jun 2001 07:10:53 -0700
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:<XRcT6.38998$[EMAIL PROTECTED]>...
> "sisi jojo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > "Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
> news:<ebvtZ6S7AHA.201@cpmsnbbsa09>..
> >
> > I don't have much time to write long messages today. But here's my answer
> >
> > Maybe the approach is wrong. That's why nobody can solve it.
> >
> > You go through years of education to learn the wrong approach, which is
> > proven to be not useful. That's something funny about our education
> system.
> >
> > If you want a problem to be solved, show it to a kid and let him develop
> > an answer fresh from the beginning.
Replying to "sisijojo":
You need a certain minimal background and mathematical maturity before
tackling hard problems. You need experience in knowing what works and
what doesn't work. The idea that some naiive "kid" will pop out of nowhere
and solve a hard problem "BECAUSE HE HAS NOT LEARNED THE WRONG APPROACH"
is ludicrous.
It also takes sophistication to know when elementary approaches to a problem
can never work. For example, consider attempts (by amateurs) to prove FLT
by considering the equation mod p, for one or more primes p, then attempting
to draw conclusions about the equation over Q from deductions about the
equation mod p. This approach can never work. But it takes an understanding
of graduate level math to understand why. There is a theorem, due to Minkowski
which tells us when one can pass from solutions of a diophantine equation
over a local field to solutions over a global field (such as Q). It takes
deep knowledge of elliptic curves to understand that the Selmer group of
the elliptic curve associated with the Fermat equation is non-trivial and
that Minkowski's theorem applies only when the Selmer group IS trivial.
The idea that one gets better results by increased ignorance is crazy.
>
> Um afaik NFS was developped by Arjen K. Lenstra
replying to "Tom"
It depends on what one means by "developed". A. Lenstra & M. Manasse
were the first to do an (almost) full implementation. Since they used
Couveignes' algorithm for computing the square root they were restricted to
odd degree fields.
But they did not develop the math.
It was originally invented (using cubic fields only) by John Pollard.
This version was the "special cubic number field sieve".
It became immediately obvious to a lot of people that it could be generalized
to handle arbitrary integers using arbitrary polynomials, but Joe Buhler,
Hendrik Lenstra Jr. (not Arjen) and Carl Pomerance were the first to wade
through all that was necessary to make it work and to analyze the method.
[This was excellent work by them!]
It was also necessary to find a way to deal with non-UFD's and compute
square roots in the number field [work by Adleman, Couveignes and Montgomery],
and to deal with much larger matrices than encountered by QS [work by
Coppersmith, Montgomery, Odlyzko, and others]
Some of the other tools needed were already in place: Cantor & Zassenhaus had
given a very fast method for finding roots of a polynomial modulo primes.
Shanks had given us SQUFOF: a very fast method for splitting double-precision
composites [needed to make the 2-large prime variation work]. Lenstra,
Lenstra & Lovasz had given a fast method for lattice basis reduction; needed
by Montgomery for his square root algorithm. etc. etc.
NFS really is not a single algorithm. It is a collection of algorithms.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 14:04:22 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Very dumb question: If the opponent has a bunch of
: encrypted messages, some with high, others have low
: entropy, how is he going to have an idea of which is
: which? Thanks.
It's hard to answer that without knowing things like whether
the messages are transmitted under the same key.
Presumably each message will have the entropy in the key, and
the entropy in the original message.
Assuming that the entropy in the key is some fixed quantity
(e.g. 128 bits worth per message), your question boils down to
how can the opponent find the entropy in the plaintexts of the
encrypted messages.
To do this, he would probably have to decrypt the messages and
see how often each one arose.
Actually measuring entropy is often difficult in practice.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: [EMAIL PROTECTED] (Bob Silverman)
Subject: Re: Definition of 'key'
Date: 6 Jun 2001 07:13:19 -0700
[EMAIL PROTECTED] (Patrick Aland) wrote in message
news:<[EMAIL PROTECTED]>...
> I was talking to someone today and we were trying to come up with a
> good formal definition of a key (in regards to cryptography, no
> car/house/etc key comments please :) )
> Now after looking through the few crypto books I have (Applied crypto,
> etc) they don't seem to have a good definition either.
> Can anyone help me out?
Sure! :-) :-)
There are all kinds of keys: donkey, turkey, monkey, Tukey, whiskey, latkey
(sic) etc.
Hope this helps!
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 14:10:22 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:> JPeschel <[EMAIL PROTECTED]> wrote:
:>: That's an OTP and its secrecy is perfect.
:>
:> Not according to the definition of perfect secrecy. Perfect secrecy
:> implies there's no information about the plaintext in the cyphertext.
: You're confusing traffic analysis with cryptanalysis. [...]
Nope.
: The content of the message is completely unknown. [...]
Nope.
: Cryptographically, that's perfect secrecy. [...]
It would be if it were true, but it is not.
I recommend you look up the definition of perfect secrecy.
Here is an URL to help you:
http://www.io.com/~ritter/GLOSSARY.HTM#PerfectSecrecy
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: S Degen <[EMAIL PROTECTED]>
Subject: Brute-forcing RC4
Date: Wed, 06 Jun 2001 16:33:40 +0200
Howmuch time would it take to brute-force a 40 bit RC4 key? (Ofcourse
depending on the processor-speed, but lets say a PIII 500)
This is the case:
You have a 128 bit (ASCII) text, and the encyphered version of it. This
version is encyphered with a 64 bit secret key, but of those 64 bits, 24
bits are known. (Leaving 40 unkown bits)
I would like to know how long it would approximately take to calculate
the 40 bit secret key.
(Worst case scenario)
Thank you if you can help me.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: fast CTR like ciphers?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 14:36:17 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: I was just thinking. It's probably very easy to make a super-fast cipher
: thats made for one-way encryption for CTR modes....?
: We could make a UFN which favors the encryption direction for diffusion and
: designed to be fast?
My understanding is that what this application requires is a PRF - not a
block cypher.
A block cypher will run into birthday effects around 2^(half the block
size) blocks and - as you point out - goes to great lengths to be
invertible, which isn't necessary (and indeed is positively
undesirable) in a CTR mode application.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: fast CTR like ciphers?
Date: Wed, 06 Jun 2001 17:11:07 +0200
Tim Tyler wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> : I was just thinking. It's probably very easy to make a super-fast cipher
> : thats made for one-way encryption for CTR modes....?
>
> : We could make a UFN which favors the encryption direction for diffusion and
> : designed to be fast?
>
> My understanding is that what this application requires is a PRF - not a
> block cypher.
Well, in that case the attacker can distinguish the message stream from
a random stream. That's still a long way away from getting at the key
or the message text.
There was some paper discussing that in detail and once you got through
the math it was relatively straightforward.
IIRC you attack a ctr-prp by simply collecting (or somehow remembering)
the counter values that have passed. Apart from a known plaintext-attack
on the underlying block cipher, you have now an ever shrinking set
of possible blocks. The more values are used up the smaller the set.
In which case attacks on the plaintext structure become more feasible.
IMHO it is *not* the case that, if you encrypt a bit more than 2^(half
the block size) with a 128bit cipher your little sister will be able to
read your messages and get your key.
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: [EMAIL PROTECTED] (Tom St Denis)
Subject: Factoring via BBS cycle length
Date: 6 Jun 2001 08:17:20 -0700
I got bored in math class (intro algebra stuff... complex numbers
etc...)
And developped a neat algorithm.
Let's suppose you have an unfactored BBS prime (blum integer) N and
don't know the factors. You then guess some integer A such that A^2 =
B, B^2 = A or in other words the period is two.
We then can re-write this as
A^2 = B
A = B^2
then via subtraction as
A^2 - A = B - B^2
Then
A^2 + B^2 = A + B
This happens to be true. Consider N=15, A=B=10. You get 10^2 + 10^2
= 10 + 10 (all mod N).
We can now use the GCD of (A+B,N) to factor N (in this case the GCD is
5).
Similarly with N=14 we get A=2,B=4 thus
2^2 + 4^2 = 2+4 (mod 14)
4 + 16 = 6 (mod 14)
6 = 6
GCD(6, N) = 2, and 2 does divide N.
Now consider extending this such that
\sum^N {P_n^2} = \sum^N P_n
If this occurs we get GCD(\sum^N P_n, pq) (pq are the primes) equal to
a factor.
So we can repeatedly square and sum until the two sums are equal.
When this occurs we have found a nontrivial factor.
Unfortunately I see no shortcut for this. It can be extended to
A^2 = bN + A
Where get
(A^2/N) - (A/N) = b
but since A,N and b belong to the set of integers the only solution is
when A ismultiple of zero (where we get 0^2 = 0 mod N).
Thus this trick cannot be used to factor other than by brute force.
My last question/item of discussion, is has this been discussed before
and if so by whom? I'm sure I haven't invented "factoring by sum of
squares" so it would be nice to read up on this!
Tom
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Brute-forcing RC4
Date: Tue, 05 Jun 2001 13:51:58 +0200
Hi.
S Degen wrote:
>
> Howmuch time would it take to brute-force a 40 bit RC4 key? (Ofcourse
> depending on the processor-speed, but lets say a PIII 500)
Don't really know about a P3/500, but compare
In my home lab i did a brute force estimate once on RC4
(including all key setups and guessing).
Using:
1 x P1/133 acting as a job server
1 x P2/266 - slave client
1 x AMD K6/350 - slave client
1 x P3/700 (Bus can be clocked to 117 Mhz; == ~819 Mhz)
..i estimated that with a C++ plugin for each slave
client, i could brute force a 2^40 key in roughly 180
days.
The computing power could be compared to 2 to 2.5 P3/500,
so, if my guess is correct, around 180 x 2 (or 2.5) days.
>
> This is the case:
> You have a 128 bit (ASCII) text, and the encyphered version of it. This
> version is encyphered with a 64 bit secret key, but of those 64 bits, 24
> bits are known. (Leaving 40 unkown bits)
Is this text always 128 bits? Are there fixed fields or headers in it?
Then there are a more efficient attack.
> I would like to know how long it would approximately take to calculate
> the 40 bit secret key.
Calculating the K and guessing (by brute force) are 2 separate things.
> (Worst case scenario)
Worst case scenario is bruteforce.
>
> Thank you if you can help me.
NP.
.Reg's,
Ichinin
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Date: Wed, 06 Jun 2001 17:33:46 +0200
Tim Tyler wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> : Very dumb question: If the opponent has a bunch of
> : encrypted messages, some with high, others have low
> : entropy, how is he going to have an idea of which is
> : which? Thanks.
>
> It's hard to answer that without knowing things like whether
> the messages are transmitted under the same key.
>
> Presumably each message will have the entropy in the key, and
> the entropy in the original message.
>
> Assuming that the entropy in the key is some fixed quantity
> (e.g. 128 bits worth per message), your question boils down to
> how can the opponent find the entropy in the plaintexts of the
> encrypted messages.
>
> To do this, he would probably have to decrypt the messages and
> see how often each one arose.
>
> Actually measuring entropy is often difficult in practice.
There is the term 'apriori probability of a message'.
Basically I am wondering whether it is 'practically'
feasible at all to determine that quantity. Even if the
opponent has at his disposal a lot of plaintexts of
the past, he can hardly know the probability of a
new message. Note that each new message is 'new', i.e.
different from all the past messages (excepting in
very rare circumstances) and generally one sends over
a channel a mixture of different kinds of messages
in an unpredictable ordering. Or maybe I am pondering
on an entirely wrong track?
M. K. Shen
========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: fast CTR like ciphers?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 15:33:38 GMT
Volker Hetzer <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
[fast primitive for CTR mode]
:> My understanding is that what this application requires is a PRF - not a
:> block cypher.
: Well, in that case the attacker can distinguish the message stream from
: a random stream.
What - if a PRF is used to generate it?
It appears to be not as easy if a block cypher of equivalent width was
used - assuming neither of the cryptographic primitives in question are
themselves broken.
: IMHO it is *not* the case that, if you encrypt a bit more than 2^(half
: the block size) with a 128bit cipher your little sister will be able to
: read your messages and get your key.
My little sister wouldn't know what to do with 2^(half the block size)
blocks.
While I believe it's customary to describe any system where there's
a faster attack than brute force as being broken, I don't think
this case is much of a concern if the opponent is one's little sister.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Barry Margolin <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Wed, 06 Jun 2001 15:36:51 GMT
In article <[EMAIL PROTECTED]>,
wtshaw <[EMAIL PROTECTED]> wrote:
>If my doctor violated his position, he would have to answer for it to me.
>I try to deal with trustworthy people to start with, and most
>professionals are.
Of course. But in emergencies you generally don't have the freedom to
choose who to deal with, or even the knowledge of who is trustworthy (you
don't have the time for a background check when you're in the ER), yet
emergency personnel may need access to your personal information.
If we could trust all professionals to act ethically, we wouldn't need
privacy laws in the first place.
--
Barry Margolin, [EMAIL PROTECTED]
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Date: Wed, 6 Jun 2001 15:12:37 GMT
[EMAIL PROTECTED] wrote:
> And the idea doesn't even ``seem'' obvious, because of one fact you
> keep ignoring: even if BICOM gives a bijection of binary files to
> itself, almost all preimages under BICOM are not in fact plausible
> messages. There is no a priori reason to believe that potential
> decrypts will be rich in plausible messages; indeed it seems rather
> unlikely.
It *is* unlikely. To fix this, one has to use a reasonable source-
model based encoding/compression. General-purpose compressors don't
"prefer" one possible plaintext over another.
However, a BiCom feature is that while most preimages may be
implausible, at least there are no *impossible* preimages.
That is a step forward, albeit a modest one
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Date: Wed, 6 Jun 2001 15:19:44 GMT
David Hopwood wrote:
> is indeed precisely why compression doesn't hinder an attacker
> in recognising plaintext.
Actually it does, in (at least) two ways.
(1) Even if a complete decryption is performed, more work is
required to recognize plaintext, *especially* in a system like
D.Scott's where the entire file must be decompressed before
plaintext emerges.
(2) Shorter ciphertext means less redundancy, which means that
recovering plaintext is much harder. The same information
content is present, but it's less accessible.
I will agree that the word "entropy" has been misused in this
thread..
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Date: Wed, 6 Jun 2001 15:30:39 GMT
Tim Tyler wrote:
> It's hard to answer that without knowing things like whether
> the messages are transmitted under the same key.
> Presumably each message will have the entropy in the key, and
> the entropy in the original message.
> Assuming that the entropy in the key is some fixed quantity
> (e.g. 128 bits worth per message), your question boils down to
> how can the opponent find the entropy in the plaintexts of the
> encrypted messages.
> To do this, he would probably have to decrypt the messages and
> see how often each one arose.
> Actually measuring entropy is often difficult in practice.
The problem is that entropy (like all knowledge) is contextual.
Once you *have* an actual data sample, to *you* it now has 0
entropy. One point of Shannon's work is that when you obtain
information it amounts to a transfer of entropy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Date: Wed, 6 Jun 2001 15:25:07 GMT
"SCOTT19U.ZIP_GUY" wrote:
> It just that the cipher text output is what is the
> easiest to get and where bijective compression helps the
> most. Bijective compression defintely makes ciphertext
> only attacks much harder.
I agree with this. The next obvious question is whether
the same is just as true for *any* old compression scheme.
I think it's evident that a 2-phase (forward;backward)
compression has a theoretical edge over forward-only
compression in this application.
------------------------------
From: "Robert J. Kolker" <[EMAIL PROTECTED]>
Subject: Re: function notation (injection, bijection, etc..) one last time
Date: Wed, 06 Jun 2001 11:40:54 -0400
Tom St Denis wrote:
> It seems each time I ask people feud over terminology.
>
> Let me try again :-)
>
> Injection. Any function that is one to one. Each element of the domain
> maps to one unique element of the codomain.
Nit. By definition of a function any element of the domain has but one
value in the co-domain. The correct definition of 1-1 is that distinct
elements of the domain map to distinct elements of the co-domain.
That is to say: if x != y then f(x) != f(y) where f is the function.
>
> Bijection. Any function F : A => B, where all elements of A point to unique
> elements of B (required to be an injection), and A and B have the same
> cardinality (required by the surjection requirement). Or is it enough that
> #B <= #A?
>
> Is that even remotely correct?
No. One requires in addition to being 1-1 that the mapping is a surjection.
Hence a bi-jection has a well defined inverse.
For example the mapping k -> 2k is an injection from the integers to
the integers which is not a bijection. Yet the co-domain of the function
has the same cardinality (i.e. aleph-0) as the domain.
There are just as many even integers as there are integers.
Bob Kolker
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Wed, 06 Jun 2001 17:44:48 +0200
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Mok-Kong Shen) wrote:
> >"SCOTT19U.ZIP_GUY" wrote:
> >>
> >[snip]
> >> If the defination is true. Then for the set of message to be
> >> encrypted. The key has to be as long as the longest message.
> >> If a shorter cipher text is sent then you have learned that the
> >> longest message was not sent. That is information about secret
> >> message. It violates Shanons defination.
> >
> >I have a dumb question: If I have a short message to
> >send and the key is longer, what should I do? Need I
> >pad it to the length of the key and send that longer
> >stuff? Thanks.
> Its not a dumb question. Most of the time you don't
> need perfect security. But if you have a wide mix
> of messages I would try to pad in a bijective way to
> some minimum size. However being secure and perfectly
> secure are two different things. ANd in general if you
> have a short message less than the key it most likely
> can't be solved for. All that may be required for safety
> is that many keys lead to a false solution. All perdect
> security really does is give "zero information". But just
> like an OTP is not practical in most cases. Sending long
> encrypted messages is not pratical either. It is just
> somthing to think about. For example if your ecnrypting
> an an anwser to a yes no question some one asked. And it
> is known you will answer "yes" or "no" it would be foolish
> to use somthing as weak as AES in CTR mode where file length
> does not change. Since attacker would know "XQ" is no
> while "RTG" is yes.
My problem is more with your citation about the length
of OTP. My understanding hithertofore is that OTP is
supposed to be a very long bit sequence that is securely
transported to the communication partner and used
in sequential order (one part after another) for many
messages irrespective of their length. If that sequence
is used up, the partner has to be supplied with a new
sequence. So both (fairly) long and short messages could
be sent securely (if the OTP is from an ideal source)
and the length of them has no implication about the
security of using OTP (unless there are other factors
that link the length to the content of the messages).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Wed, 06 Jun 2001 18:04:21 +0200
Barry Margolin wrote:
>
> wtshaw <[EMAIL PROTECTED]> wrote:
> >If my doctor violated his position, he would have to answer for it to me.
> >I try to deal with trustworthy people to start with, and most
> >professionals are.
>
> Of course. But in emergencies you generally don't have the freedom to
> choose who to deal with, or even the knowledge of who is trustworthy (you
> don't have the time for a background check when you're in the ER), yet
> emergency personnel may need access to your personal information.
>
> If we could trust all professionals to act ethically, we wouldn't need
> privacy laws in the first place.
I suppose that, like all practical issues in the world,
one has to accept compromises. It is essential that
in emergency cases the medical personal has immediate
access to all health relevant data. On the other hand,
implementing a tight protection system is not only
difficult but costly. So having some laws more or less
well preventing improper handling of medical informations
and have a good auditing in all kinds of patient
data bases is likely to be all what one can realistically
do.
M. K. Shen
------------------------------
Subject: Re: Def'n of bijection
From: [EMAIL PROTECTED]
Date: 06 Jun 2001 12:09:38 -0400
"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>
> However, a BiCom feature is that while most preimages may be
> implausible, at least there are no *impossible* preimages. That is
> a step forward, albeit a modest one
Granted. I think we're agreed here; I've said ``all it does is add work,''
and you're saying ``adding work is good.'' Fair enough.
Len.
--
Full disclosure frightens you? Great! You now have more incentive to
support secure software.
-- Dan Bernstein
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
