Cryptography-Digest Digest #531, Volume #14 Tue, 5 Jun 01 23:13:01 EDT
Contents:
Re: Def'n of bijection (SCOTT19U.ZIP_GUY)
Re: PRP => PRF (TRUNCATE) ("Scott Fluhrer")
Re: One last bijection question (Nicol So)
Re: fast CTR like ciphers? ("Scott Fluhrer")
Re: One last bijection question ("Robert J. Kolker")
Re: One last bijection question (Nicol So)
Re: fast CTR like ciphers? ("Tom St Denis")
Re: Quantum Computers with relation to factoring and BBS ("rosi")
function notation (injection, bijection, etc..) one last time ("Tom St Denis")
Re: function notation (injection, bijection, etc..) one last time
([EMAIL PROTECTED])
Re: function notation (injection, bijection, etc..) one last time (Nicol So)
Re: function notation (injection, bijection, etc..) one last time (Nicol So)
Re: Quantum Computers with relation to factoring and BBS (Nicol So)
Re: Knapsack security??? Ah....huh ("rosi")
Re: function notation (injection, bijection, etc..) one last time
([EMAIL PROTECTED])
Re: Medical data confidentiality on network comms (wtshaw)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Def'n of bijection
Date: 5 Jun 2001 23:55:57 GMT
[EMAIL PROTECTED] (David Hopwood) wrote in
<[EMAIL PROTECTED]>:
>
>is indeed precisely why compression doesn't hinder an attacker in
>recognising plaintext. Compression cannot change the total entropy of
>the messages sent under a particular key: that is determined by the
>usage characteristics of the application. Once sufficient messages have
But Dave even you should know something about Shannons theorys.
If you compress you can increase the entropy per bit of the message
by the very fact of compression. And you miss a big point. For
many message with out comprssion they can be breakable becasue
message is far greater than the Unicity distance. But that same
message may be unbreakable with compression. Not only because it
takes less cipher space but because the message may be less than
the Unicity distance.
However I admit for very long files its unlikely that the
either message is shorter than the Unicity distance so if
one could check all messages either with compression or without
you would get the correct message. But you forget even yet
another problem with modern ciphers the fact that error propagation
is very low. That means if an attacker knows part of message. He
need only attack the blocks where that portion of message is to
obtain a break. With say bijective arithmetic compression if he
knows what part of file is say half way down. The attacker needs
to decrypt and uncompress everything up to and including that
point to get a test case. It may be that with a known portion
of plain text a fast way to break those blocks may be possible.
With Arihtmetic compression even if you knew what the compressed
plain text was. It would be very hard to decompress a middle
portion of a file. As such its less likely that a simple math
short cut could be used on that portion of the file.
>been sent under a given key, there will be enough information to
>brute-force it [*]. If we assume that the key size is fixed (i.e. not an
>OTP), then compression makes no significant difference to when this
>happens. Even though the distribution of decrypts will be a little
>closer to the distribution of meaningful messages than it would
>otherwise have been, in practice it will there will still only be one
>decrypt that is actually meaningful, and it will be easy to recognise
>that decrypt automatically, for message distributions that occur in real
>applications. Note that this is true even if codebooks are used, since
>the messages in a typical codebook don't have anywhere near equal
>probability of occurrance.
>
>
>[*] I know that David Scott handwaves about other attacks than
>brute-force.
> However, he hasn't put forward any coherent argument as to how
> bijective compression would help against such attacks. Note that
> cryptanalytic attacks against commonly used block ciphers generally
> require large amounts of *exact* known plaintext (at least). In
> plausible situations where exact known plaintext would be available
> - when data streams from multiple sources are encrypted under the
> same key, for example - then it would be available whether
> compressed or not.
If one has the plaintext which I don't think Ben laden or terriost
are likely to give. Yes either compression or no compression.
You could figure out the key. As I have stated several times
this compression encryption does nothing to stop a full dumb
blind brute force seach if you have a plaintext file in and
a cipher text file out and the time to do it.
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.
May I keep finding exceptions. But since hopefully a compressed
file is so much shorter than a plain text file. Its entirely possible
that more than one key could map to the same compressed text. So having
a single key may not completely enough. Toms exaple of CTR mode
there are only 256 message ouput if its a one byte file. But I think
several of the 2**256 key would map the same way for the single byte
but as soon as you get two byte it changes.
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: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: PRP => PRF (TRUNCATE)
Date: Tue, 5 Jun 2001 18:11:17 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:dW8T6.34800$[EMAIL PROTECTED]...
>
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> news:9fisbo$ngc$[EMAIL PROTECTED]...
> >
> > Tom St Denis <[EMAIL PROTECTED]> wrote in message
> > news:VC2T6.31386$[EMAIL PROTECTED]...
> > > Reading the paper David pointed to a bit ago I see they have one way
to
> go
> > > from PRP to PRF by truncating bits of the output.
> > >
> > > Obviously there will be alot of PRPs that make the same PRF. Wouldn't
a
> > > better method of truncating be reducing modulo a prime?
> > >
> > > I.e if you want a four bit PRF you do (PRP mod 17) mod 16 = PRF. That
> way
> > > the higher order bits will affect the output. Did I misunderstand the
> > > original intent?
> > Well, yes. For one, if you assume a perfect PRP, what advantage would
> your
> > approach have over simple truncation? He achieved a provable result --
> can
> > you make the analogous proof with your more complicated method.
>
> Well the problem is there will be many collisions. For example if you
> truncate 7 bits to get a 8 => 1 function you can have any permutation of
the
> upper 7 bits to get an equivalent system (i.e (2^7)!).
I'm sorry, but why is that a problem, and how does your method "fix" it?
The question that Wagner was addressing is "We have a PRP, we need a PRF
with a smaller output, what result can be achieve which is provable?". In
fact, because (if we make the PRF output sufficiently short compared to the
PRP output), it's rather innevitable, because in that case, there are more
PRP's than PRF's, and so any method of answering that question will have the
same "problem".
--
poncho
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: One last bijection question
Date: Tue, 05 Jun 2001 21:33:32 -0400
Reply-To: see.signature
Thorsten Holz wrote:
>
> Tom St Denis wrote:
> >
> > Ah so surjective functions are not one-to-one?
The property of being surjective is not the same as the property of
being one-to-one (injective). A surjective function can be one-to-one
(as in the case of a bijection).
> No - they are "many-to-one"...
Functions are in general many-to-one. "Many-to-one" does not capture the
essence of surjective functions.
> Set A has more elements than set B - and every element of B is "hit"
> by the function f at least once.
There's no requirement that the domain is of a higher cardinality than
the codomain.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: fast CTR like ciphers?
Date: Tue, 5 Jun 2001 18:25:01 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:TsbT6.37526$[EMAIL PROTECTED]...
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:U_aT6.37003$[EMAIL PROTECTED]...
> > 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?
>
> Just to start the discussion I have a toy cipher (designed in all of five
> mins) that we can use as a model of discussion.
>
> I call it MUD for "Mirky UnderDeveloped". it's not intended for real
> use....
>
> It's somewhat fast and on 8-bit cpus would be a dream to implement. The
> idea is that the cipher is used in CTR mode only so the decryption is
> neither required nor provided. The cipher is designed such that going
from
> plaintext to ciphertext is secure but not the vice versa...
>
> http://tomstdenis.home.dhs.org/src/mud.c
Could you double-check the URL? I'm getting errors.
--
poncho
------------------------------
From: "Robert J. Kolker" <[EMAIL PROTECTED]>
Subject: Re: One last bijection question
Date: Tue, 05 Jun 2001 21:40:17 -0400
Stanley Chow wrote:
>
> Bijection means that A and B are "essentially" the same; it does
> not mean they "are" the same.
>
> Another way of saying it is that A and B are isomorphic (which
> means there is a bijection/isomorphic map between A and B). Very
> circular, but the distinction is important.
Let me pick a nit. Isomorphism is not just any old 1-1 onto mapping.
It is a mapping that preserves the mathematical structure of the sets.
For example if f:A<->B (bijection) and A and B are groups it is
required that f(a op_A b) = f(a) op_B f(b)
where op_A is the group operation in A and op_B is the group
operation in B.
Similar for other sets with some kind of operator or algebraic
structure. So an * isomorphism * is more than a 1-1 onto map.
It is a structure preserving map.
Bob Kolker
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: One last bijection question
Date: Tue, 05 Jun 2001 21:41:28 -0400
Reply-To: see.signature
"Douglas A. Gwyn" wrote:
>
> Tom St Denis wrote:
> > Ok I thought bijections were when the codomain and domain are the same set.
>
> No, the codomain is in the range (output) set, not the domain
> (input) set. These can be totally separate spaces with
> different properties (measured in different units, etc.).
>
> A bijection is a surjection that is also an injection.
>
> A surjection "covers the entire range"; for each element
> in the range, there is at least one element in the domain
> that maps to it.
A comment on the terminology: the range of a function f is the image of
the domain under f. The codomain of a function is a (not necessarily
proper) superset of its range.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: fast CTR like ciphers?
Date: Wed, 06 Jun 2001 01:51:20 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:9fk1i4$aaf$[EMAIL PROTECTED]...
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:TsbT6.37526$[EMAIL PROTECTED]...
> >
> > "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> > news:U_aT6.37003$[EMAIL PROTECTED]...
> > > 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?
> >
> > Just to start the discussion I have a toy cipher (designed in all of
five
> > mins) that we can use as a model of discussion.
> >
> > I call it MUD for "Mirky UnderDeveloped". it's not intended for real
> > use....
> >
> > It's somewhat fast and on 8-bit cpus would be a dream to implement. The
> > idea is that the cipher is used in CTR mode only so the decryption is
> > neither required nor provided. The cipher is designed such that going
> from
> > plaintext to ciphertext is secure but not the vice versa...
> >
> > http://tomstdenis.home.dhs.org/src/mud.c
>
> Could you double-check the URL? I'm getting errors.
Stupid windows... arrg I think my server was not running try
http://24.112.8.23:8080/src/mud.c
BTW the design is not suppose to be secure. So I won't be surprised if you
break it.
The point of posting this is to highlight a new design philosophy. The idea
is we want a block cipher were we can sacracfice alot as long as the
encryption routine is secure. I.e Guessing the output is hard without the
key.
The idea is that the cipher will be used in either a hash or CTR mode of
operation.
The example I posted was a simple UFN with a 8-bit round function. It's
most likely not secure (although I can't see obvious breaks I bet they will
come of the form of either some impossible differential or differential that
simply cancels out and has little active sboxes).
Tom
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: Quantum Computers with relation to factoring and BBS
Date: Tue, 5 Jun 2001 23:10:15 -0400
Bob Silverman wrote in message
<[EMAIL PROTECTED]>...
>[EMAIL PROTECTED] (Bill Unruh) wrote in message
news:<9eu1ke$njh$[EMAIL PROTECTED]>...
>> In <9etv2h$4pn$[EMAIL PROTECTED]> "Scott Fluhrer"
<[EMAIL PROTECTED]> writes:
>> ]>
>> ]> 1. Do we know factoring is NP for certain?
>
><snip>
>>
>> But asking "is a problem NP" is usually a shorthand for
>> "Is the problem NP but not P".
>
>Since when??? It most certainly is NOT such a shorthand.
A little surprised to see 'most' instead of 'absolutely'.
So in your spirit, Bill is not really wrong? I can not help wondering,
after seeing all those
discussions by thoughtful and intelligent people with such a variety of
opinions on such a
single issue, that maybe there is some reason. And I can hardly doubt that
people, those
that are not uneducated, do ask the question in the sense Bill hinted.
Otherwise, 'it is in NP',
but so what?
But please, I doubt if I ask in exactly the same sense, even though I do
not think asking in
such a sense is such a big deal. It is alright to me. Not alright with the
rest of the world? So
what? I do not think you have erred anywhere, but Bill certainly, in my
opinion, deserves being
defended whether he wants to be defended or not.
> "Is a problem in NP?" is a well-defined, unambiguous question.
Well-defined? Yes! Unambiguous? Sure! But how about replacing the word
'question'
with something else, for example, 'piece of ...'? :)
Again, what NP stands for? :)
--- (My Signature)
>
>> Factoring is probably NOT NP complete. But it is probably also not in P
>
>The fact that we have a sub-exponential time algorithm is evidence for the
>first statement. However, we have no evidence for the latter except our
>own ignorance.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: function notation (injection, bijection, etc..) one last time
Date: Wed, 06 Jun 2001 01:58:16 GMT
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.
Surjection. Any function where all the elements of the codomain can be
mapped from the domain. This could be one to one or many to one. I.e the
function F : {x in Z | isprime(x) } is surjective since all boolean values
can be mapped to.
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?
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
Subject: Re: function notation (injection, bijection, etc..) one last time
From: [EMAIL PROTECTED]
Date: 05 Jun 2001 22:07:49 -0400
"Tom St Denis" <[EMAIL PROTECTED]> writes:
>
> Injection. Any function that is one to one. Each element of the domain
> maps to one unique element of the codomain.
Correct.
> Surjection. Any function where all the elements of the codomain can be
> mapped from the domain. This could be one to one or many to one.
Correct.
> 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).
Correct.
> Or is it enough that #B <= #A?
No, you were right the first time.
Len.
--
Legitimate standards organizations never have any trouble showing people
the justifications for their decisions.
-- Dan Bernstein
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: function notation (injection, bijection, etc..) one last time
Date: Tue, 05 Jun 2001 22:15:07 -0400
Reply-To: see.signature
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.
I think you get the idea but your wording is slightly problematic.
"Unique" here could be misinterpreted as being single-valued. Functions
are by definition single-valued.
> Surjection. Any function where all the elements of the codomain can be
> mapped from the domain. This could be one to one or many to one. I.e the
> function F : {x in Z | isprime(x) } is surjective since all boolean values
> can be mapped to.
The verbal description is right but the notation does not conform to
accepted math usage.
> 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?
You almost got that right, except that "A and B have the same
cardinality" is not the correct condition, because A and B could be
infinite. Here's an illustrative example:
A = B = set of all natural numbers
f(x) = x+1 for all natural number x
Now, no two elements in A map to the same element in B under f
(injectivity), and #(A) = #(B), but f is not bijective (0 doesn't have a
pre-image under f).
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: function notation (injection, bijection, etc..) one last time
Date: Tue, 05 Jun 2001 22:17:27 -0400
Reply-To: see.signature
[EMAIL PROTECTED] wrote:
>
> "Tom St Denis" <[EMAIL PROTECTED]> writes:
> >
> > 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).
>
> Correct.
No. See my example in another message.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Quantum Computers with relation to factoring and BBS
Date: Tue, 05 Jun 2001 22:29:52 -0400
Reply-To: see.signature
rosi wrote:
>
> Bob Silverman wrote in message
> <[EMAIL PROTECTED]>...
> >[EMAIL PROTECTED] (Bill Unruh) wrote in message
> news:<9eu1ke$njh$[EMAIL PROTECTED]>...
> >> In <9etv2h$4pn$[EMAIL PROTECTED]> "Scott Fluhrer"
> <[EMAIL PROTECTED]> writes:
> >> ]>
> >> ]> 1. Do we know factoring is NP for certain?
> >
> ><snip>
> >>
> >> But asking "is a problem NP" is usually a shorthand for
> >> "Is the problem NP but not P".
> >
> >Since when??? It most certainly is NOT such a shorthand.
>
> A little surprised to see 'most' instead of 'absolutely'.
"Most certainly" means certainty to the highest degree. Bob was not
expressing reservation or in any way qualifying his assertion.
> So in your spirit, Bill is not really wrong? I can not help wondering,
> after seeing all those
> discussions by thoughtful and intelligent people with such a variety of
> opinions on such a
> single issue, that maybe there is some reason. And I can hardly doubt that
> people, those
> that are not uneducated, do ask the question in the sense Bill hinted.
> Otherwise, 'it is in NP',
> but so what?
>
> But please, I doubt if I ask in exactly the same sense, even though I do
> not think asking in
> such a sense is such a big deal. It is alright to me. Not alright with the
> rest of the world? So
> what? I do not think you have erred anywhere, but Bill certainly, in my
> opinion, deserves being
> defended whether he wants to be defended or not.
>
> > "Is a problem in NP?" is a well-defined, unambiguous question.
>
> Well-defined? Yes! Unambiguous? Sure! But how about replacing the word
> 'question'
> with something else, for example, 'piece of ...'? :)
What Bob said was correct. You should take his comment seriously.
> Again, what NP stands for? :)
NP stands for "non-deterministic polynomial-time". It is a well-defined
class of languages. When a problem is phrased as a language recognition
problem, either it is in NP, or it is not. So in that sense, the
question is well-defined.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: Knapsack security??? Ah....huh
Date: Tue, 5 Jun 2001 23:44:19 -0400
I think I have "THE" issue nailed. But are you guys serious? Please let
me know.
Thanks
--- (My Signature)
P.S.
If you are really serious, you either have to remove the word 'still'
in:
I was wondering if there are any knapsack systems that
are still secure.
or you have to define what this 'still secure' is. (Kind of kidding here,
for I think I
roughly know what you mean by 'still'). You know, 'provably secrure' can get
everybody preoccupied for the rest of his/her life, and we may not need
another
such. :)
But seriously, I can modestly offer if you are really serious. But there
are a
few requirements. You are to try to answer a few half-technical questions
(after
reading what I offer). It does not matter if you can get them right as long
as you
really try. Of course, you need to have some basic technical knowledge, such
as
what isomorphic is and what ordering is. You do not have to be expert on
such
topics (for I am none), you just have to know what approximately they are.
Since
you are asking about knapsack systems, I assume you can read simple formal
notations and have a rough (just rough) idea about NP-completeness and
related
issues such as LLL. Besides, we will go slowly. So please let me know.
John Bailey wrote in message <[EMAIL PROTECTED]>...
>On 3 Jun 2001 21:32:07 -0700, [EMAIL PROTECTED] (Merc42)
>wrote:
>
>>I was wondering if there are any knapsack systems that are still
>>secure. Any that don't use modular arithmatic to change the keys are
>>of special interest to me. Furthermore, if anybody does know of any,
>>could you please tell me some reference where i could learn more about
>>them. As always, any help is appreciated...
>
> I wonder too. This post in January on this news group did not get
>any responses.
>
>(quoting myself)
>I was amazed to note that the NTRU Public Key method:
>(reference)
>Public key cryptosystem method and apparatus
>http://www.delphion.com/details?pn=US06081597__
>is formally equivalent to a knapsack system.
>Referencing the last section of the NTRU tutorial
>http://www.ntru.com/technology/tutorials/pkcstutorial.htm
>e = r*h + m, where e is the encrypted message, h is a public key, r is
>randomly chosen and m is the message.
>The message m is recovered by finding f*e mod q mod p = m.
>In the NTRU case, e, r, h, m, and f are truncated polynomials
>whereas, in the cases mentioned at the beginning of this post, they
>would simply be large numbers. In either case, essentially the same
>modulo algebra applies, showing the recoverability of encrypted
>plaintext using private keys.
>
>Other knapsaci systems:
>A Comsat patent:
>Simple and effective public-key cryptosystem
>http://www.delphion.com/details?&pn=US04306111__
>and
>Diophantine encryption for public key encoding
>http://www.frontiernet.net/~jmb184/interests/sci.crypt/numerical_encryption
.html
>In this last one, an encrypted message e = r*h + m*k where e is the
>encrypted message, r is a random number, h and k are public key
>values, and m is the encrypted message (number) m is recovered by
>computing m = e*g mod p mod q where g, p, and q are calculated from
>the private keys.
>
>Simplified knapsack systems are easily implemented and would provide
>a nice means for simple, numeric only public key tasks such as
>symmetric key exchange except they have a history of being ultimately
>breakable.
>
>Quoting A. M. Odlyzko of Bell Labs:
>The rise and fall of knapsack cryptosystems,
>http://www.research.att.com/~amo/doc/crypto.html
>Abstract:
>Cryptosystems based on the knapsack problem were among the first
>public key systems to be invented, and for a while were considered to
>be among the most promising. However, essentially all of the knapsack
>cryptosystems that have been proposed so far have been broken. These
>notes outline the basic constructions of these cryptosystems and
>attacks that have been developed on them. (end quote)
>
>Assuming the NTRU system has a new twist, are there also other
>unexploited avenues in which the formalism for simple modulo knapsacks
>might lead to interesting public key systems? An example of such a
>system might use digital Fourier Transforms (FFT) to form knapsacks,
>along lines paralleling NTRU's use of truncated polynomials.
>
>John Bailey
------------------------------
Subject: Re: function notation (injection, bijection, etc..) one last time
From: [EMAIL PROTECTED]
Date: 05 Jun 2001 22:34:26 -0400
Nicol So <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>>
>> "Tom St Denis" <[EMAIL PROTECTED]> writes:
>>>
>>> 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).
>>
>> Correct.
>
> No. See my example in another message.
You're right; thanks. I was trying to accomodate Tom's somewhat loose
language, and ended up making careless mistakes.
Tom: I don't mind answering questions on usenet, and neither do others,
but at this point it really wouldn't hurt to pick up a math text. This
is important notation, and the definitions are quite standard. It's
not a winning plan to keep avoiding rigorous language.
Len.
--
Ah. So you give away a hard-to-use product and then sell support for it.
I guess the scam works as long as there's no competition.
-- Dan Bernstein
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Tue, 05 Jun 2001 20:35:26 -0600
In article <OaVR6.45$Ij4.774@burlma1-snr2>, Barry Margolin
<[EMAIL PROTECTED]> wrote:
> What if someone who has legitimate need to access the information
> (e.g. your doctor) decides to use it for personal gain? The system can't
> tell *why* someone is accessing data, and it can't control what they do
> with it once they have it. So a doctor could get the information while
> he's treating you, which most people feel is justified, and then publish
> details of your condition in a journal article. There's nothing that
> technology can do to prevent that.
>
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.
The answer to securing data is to present a low profile, support better
security, and expose deficient data storage. These are areas that medical
professionals are apt to not be experts at, so it is our job to support
healthy computer systems as it is theirs to support heathy bodies.
--
Sign for the White House lawn:
WARNING! Irresponsible Parents Live Here.
------------------------------
** 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
******************************
