Cryptography-Digest Digest #424, Volume #14 Thu, 24 May 01 14:13:01 EDT
Contents:
Re: Random and RSA (Darryl Wagoner - WA1GON)
Re: Medical data confidentiality on network comms (Jeffrey Williams)
Re: survey (JPeschel)
Re: Ideas for project (jlcooke)
Re: Random and RSA (jlcooke)
Re: ECB plus padding instead of CBC? ("Julian Morrison")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (John Savard)
Re: Random and RSA (JPeschel)
Re: survey ("Douglas A. Gwyn")
RSA's new Factoring Challenges: $200,000 prize. (Peter Trei)
Re: Protocol for authentication and key agreement... (Mark Wooding)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: Medical data confidentiality on network comms (Paul Rubin)
Re: Questionable security measures (Cloakware!) (Ian Stirling)
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Darryl Wagoner - WA1GON)
Subject: Re: Random and RSA
Date: Thu, 24 May 2001 15:41:16 -0000
[EMAIL PROTECTED] (those who know me have no need of my name)
wrote in <[EMAIL PROTECTED]>:
><[EMAIL PROTECTED]> divulged:
>
>>Try this algo to factor N.
>>Let S= (10^k) - 1
>>for k=N to (n/2) step -1
>>Let c=gcd(S,N)
>>if c<>1 or c<>N then c is a solution.
>>
>>I know that it's hard to hudge number but try it I think that you will
>>find a solution in less than an hour.
>
>the last rsa factoring challenge to be completed required 7.4 months for
>a 155 digit number, and required a network of over 290 computers. if
>you can find a way to do it in an hour you will be quite famous. this
>algorithm doesn't appear to work that quickly.
>
Did they get lucky or what? Is it really possible to factor a 512 bit
number in 7.4 months? It wasn't done with the algo above for
sure!
--
Darryl Wagoner - WA1GON
Join the TrustedQSL mailing list. An Open Source solution.
Post message: [EMAIL PROTECTED]
Subscribe: [EMAIL PROTECTED]
List owner: [EMAIL PROTECTED]
http://www.trustedQSL.org
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Thu, 24 May 2001 10:43:14 -0500
I have some experience working with medical folks, and lots of experience with
networks, but I've not combined the two. One suggestion I have is to assume
that your closed loop will be opened to the outside world. I've worked on a
variety of systems which were ostensibly secure. In almost every case,
including military networks, some one compromised security. More often than
not, the source of the compromise was some technically oriented user who wanted
to be able to login from home.
If you want to minimize the effort required for someone to login in a secure
manner, check out biometrics - there are apparently some new devices becoming
available which scan fingerprints, or iris patterns, or facial patterns, etc.
They might be cheap enough to be useful in your system.
Jeff
Harris Georgiou wrote:
> I'm currently working on some distributed medical image analysis &
> diagnostic system and I was wondering: what security issues (if any) are
> addressed by modern medical LAN/RDBMS systems used by hospitals or
> insurrance companies? I mean, since most of these systems run over open
> TCP/IP networks (even the Internet), how does the confidentiality and
> intergrity of personal medical info is ensured? Since my system will work as
> a "closed" loop of distributed services, I'm thinking of implementing simple
> login access control through ACLs and some basic authentication for the
> client apps and the data streams, but somehow that doesn't seem to be
> enough. I think such systems should be designed so that each (internal) node
> and storage is considered secure (provided by the OS) and all comms prone to
> eavesdropping or even tampering.
> Does anyone has experience on security details for these kinds of (medical)
> systems?
> Thanks :-)
>
> --
>
> Harris
>
> - 'Malo e lelei ki he pongipongi!'
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 24 May 2001 15:52:28 GMT
Subject: Re: survey
Douglas A. Gwyn [EMAIL PROTECTED] writes, in part:
>I suspect many other people understood the point, which could
>have been made verbosely thus: "Simplicty and speed are minor
>matters for a cryptosystem compared to its resistance to attack."
>Or: "You're concentrating on the trees at the expense of the
>forest." But a concrete example helps make the point more "real".
>
Doug,
I wouldn't call the sentence: "Simplicty and speed are
minor matters... " verbose. Nice consonance, no unneeded
words. It is, of course, less concrete than your previous
example. Perhaps, that example was so terse that Tom
felt it curt.
Your alternative example, "You're concentrating on
the trees..." is too similar to the cliche to be
effective.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: jlcooke <[EMAIL PROTECTED]>
Subject: Re: Ideas for project
Date: 24 May 2001 15:52:25 GMT
Simon West wrote:
> My primary objective is to have an interesting project
> and to pick up as much practical knowledge as possible on the way.
> Hope this allays Paul's concerns as I would be interested in any ideas he may
> have.
Then I suggest taking the task of implementing speed optimized crypto
code. Though it's not "sexy" and exciting. It will prove to be very
educating. You'll learn the innards of every algorithm you fiddle
with. For a "survey" I suggest:
2 hash algorithms
2 block ciphers
2 asymmetric ciphers
Choosing algorithms which are very different in structure and concept
will give a good workout.
Good luck.
JLC
------------------------------
From: jlcooke <[EMAIL PROTECTED]>
Subject: Re: Random and RSA
Date: 24 May 2001 15:55:05 GMT
Darryl Wagoner - WA1GON wrote:
>
> [EMAIL PROTECTED] (those who know me have no need of my name)
> wrote in <[EMAIL PROTECTED]>:
>
> ><[EMAIL PROTECTED]> divulged:
> >
> >>Try this algo to factor N.
> >>Let S= (10^k) - 1
> >>for k=N to (n/2) step -1
> >>Let c=gcd(S,N)
> >>if c<>1 or c<>N then c is a solution.
> >>
> >>I know that it's hard to hudge number but try it I think that you will
> >>find a solution in less than an hour.
> >
> >the last rsa factoring challenge to be completed required 7.4 months for
> >a 155 digit number, and required a network of over 290 computers. if
> >you can find a way to do it in an hour you will be quite famous. this
> >algorithm doesn't appear to work that quickly.
> >
>
> Did they get lucky or what? Is it really possible to factor a 512 bit
> number in 7.4 months? It wasn't done with the algo above for
> sure!
A little. They used a GNFS with several weeks on a CRAY-J90 to generate
a cleaver polynomial.
Above: It's actually a crippled Pollard P-1. S=(10^k)-1 vs S=k!
JLC
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Thu, 24 May 2001 17:31:58 +0100
"Roger Fleming" <[EMAIL PROTECTED]> wrote:
> Julian, in this post I keep referring to the mode you proposed. To avoid
> calling it "your mode", which sounds a bit personal, I will call it "CP
> mode" for "cruft padded mode".
Oo, a mode all of my own! *grins proudly*
> "Julian Morrison" <[EMAIL PROTECTED]> wrote: [...]
>>Count mode if I understand it is:
>>
>>(crypt(block-count as 16 byte bignum)) xor (crypt(16 byte data-chunk))
>
> Err, no. This may be why you're arguing at cross purposes; counter mode
> is much simpler than that. It's just:
>
> crypt(counter) xor plaintext
Hmm. Thanks. That makes it a lot more attractive than I had thought.
> Plaintext is 1-16 bytes long, as required. Counter can be _anything_
> that is highly unlikely to repeat before re-keying, and is accessible to
> the receiver. It does not have to be secret, and is commonly sent in
> clear in front of the first encrypted block. Conventionally, it's a
> counter starting from zero 'coz that's nice and simple, but something
> like the packet number is ok too (provided the opponent can't go
> manipulating packet numbers on you)..
Nah, packet number is a bad plan.
- the bad guys might be able to fiddle with it, or the OS could screw up.
- It's too short.
- What if one wanted to forward the packet via some sort of proxy, NAT,
etc?
- It will need to rekey after a reboot since the OS will not recall its
last packet number.
I like my idea of countlength, countbytes. It can carry the full 128 bit
width if necessary, and it wastes only a single byte.
> The number of bits actually
> incremented in the counter will depend on your application, but for
> nearly all real world applications only a single 32 bit add is required.
> You say that 2^32 blocks before re-keying isn't enough for your
> application; that's a pretty huge data stream!! For example, if you're
> doing voice over IP, you won't need to increment the second 32 bit word
> for more than a year! Hopefuly before then, you will have re-keyed
> anyway.
Well this is a very long lived stream because it's acting as a permanent
conduit between the two hosts, over which many transient streams/datagrams
are multiplexed. The idea being to minimize any need to recreate that
connection, so that no bad guy can scramble the line and thereby force a
DH handshake which he can MITM. Instead there would just be a simple "do
you know the key" challenge/response test and it would pick up where it
left off.
> No. Even if the receiver is _totally_ stateless (in which case, where
> does it get the key?),
Oops, meant "stateless apart from the key". Silly me.
> [...] What he meant was that counter mode (with the counter prepended as
> plaintext) offers a data expansion of a fixed number of bytes, while CP
> mode expands data by a percentage, so it will be interesting to see
> where the crossover is, ie where one becomes more efficient than the
> other. He said 4 blocks, but actually he's erred considerably in favour
> of CP mode! Let b be the number of data bytes, the counter mode expands
> to (probably) b + 4
> or maybe
> b + 8
> while CP mode expands to
> 16 b /12 = 4 b/3
> Obviously if we only use 4 bytes for the counter, CP mode is _never_
> more efficient. If we use an 8 byte counter, CP mode becomes less
> efficient when 4 b/3 > b + 8
> ie b > 24
> So if we have even two blocks per packet, CP mode wastes space as well
> as being slower.
Well count mode with a countlength, countbytes structure expands to
somewhere between b + 2 and b + 17. Which would make the efficiency math
harder, but likely still come out on top.
> Now you've said you only want to send one block (16 octets) of data per
> packet "to be sure to be less than any MTU". No modern medium uses an
> MTU smaller than 1kB (64 blocks), (ethernet is 1500 octets, BTW) and
> even the tiniest old fashioned MTUs I've ever heard of are 128 octets (8
> blocks). Using packet sizes as small as you are discussing will cause
> serious transmission inefficiencies and are simply unneccesarily small
> for fragmentation issues.
Right. Thanks, that's useful info. Would be slightly less actual data
blocks than that though because of the prepended header blurb.
> Error expansion:
> Error expansion is not a serious issue here, because we know any
> received error is likely to cause the whole packet to be dropped.
> However it is to be noted that counter mode is very resilient to bit
> flipping errors: each bit flipped will cause the garbling of exactly one
> bit. CP mode has the same error expansion poperty as ECB mode: a flipped
> bit will cause a whole block (128 bits) to be garbled.
This is very useful. It will allow me to put self-correcting info as one
possible transmission mode (eg: put an XOR byte between each pair of
bytes). Plus a MAC to see that it corrected properly.
> OK, now the biggie: security.
> [...]
> In short, CP mode is computationally less efficient, less network
> efficient, and less secure. As Mr Schneier wrote: "stay away from the
> weird modes. One of the standard modes is nearly always better".
Right. Some of those problems go away if you always use MACs, but since
you better explained count mode I can see its advantages - especially,
that I can precompute and buffer crypted counts in idle time, making a
message send just a flat bytewise XOR provided it's shorter than the
precomputed buffer.
--
I like e-gold. Digital currency based 100% in real physical gold.
This link ( http://www.e-gold.com/e-gold.asp?cid=281798 ) takes you to
their site and shows me as the introducer if you open an account.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 24 May 2001 16:33:42 GMT
On Wed, 23 May 2001 23:02:57 GMT, "Tom St Denis"
<[EMAIL PROTECTED]> wrote, in part:
>You always seem to reach for extremes. Either they are stupid know-nothings
>or "phony crypto gods". Nobody in your eyes is "competent".
Well, his basic premise is that the people who are listened to - the
people who are taken seriously - are the "crypto gods", because they
preach the (flawed!!!) conventional wisdom, and everyone looks up to
them.
Maybe there are some things about the conventional wisdom that need to
be looked at, and some of the premises (really big keys, the algorithm
being somehow unknown or variable) that amateurs keep bringing
forwards have _some_ merit to them, even if the problems that can be
pointed out in their proposals from the conventional viewpoint are
also valid.
Anyone with the slightest understanding of human nature, of course,
would know that Mr. Scott's approach is hardly the way to get anyone
to consider opening their minds and giving another point of view a
hearing.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 24 May 2001 16:32:56 GMT
Subject: Re: Random and RSA
jlcooke [EMAIL PROTECTED] writes:
>They used a GNFS with several weeks on a CRAY-J90 to generate
>a cleaver polynomial.
>
Ah, GNFS -- exactly the same way Wally
and the Beaver were generated. :-)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Thu, 24 May 2001 16:31:14 GMT
JPeschel wrote:
> I wouldn't call the sentence: "Simplicty and speed are
> minor matters... " verbose. Nice consonance, no unneeded
> words.
Thanks, but I really felt that about the code example too.
> It is, of course, less concrete than your previous
> example. Perhaps, that example was so terse that Tom
> felt it curt.
I'm not sure why Tom took it the way he did.
> Your alternative example, "You're concentrating on
> the trees..." is too similar to the cliche to be
> effective.
Interestingly, somebody else responded to him using the
same cliche at about the same time. At least I'm not
alone in my perception.
------------------------------
From: Peter Trei <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.math.research
Subject: RSA's new Factoring Challenges: $200,000 prize.
Date: Thu, 24 May 2001 16:05:31 GMT
RSA Security, has revamped its Factoring Challenges.
Prizes now start at US$10,000 (factorization of a 576 bit modulus) to
US$200,000 (factorization of a 2048 modulus).
RSA and its predecessor companies have been sponsoring factorization
challenges for many years, but until now the prize money has been
nominal. It is hoped that the increased bounties will draw more people
to the field, and spur new research.
For details, including the challenge numbers, see:
http://www.rsasecurity.com/rsalabs/challenges/factoring/index.html
Peter Trei
Cryptoengineer
RSA Security Inc.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Protocol for authentication and key agreement...
Date: 24 May 2001 17:00:15 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
> The system uses Diffie Helman, RSA and a block algorithm which I haven't
> finalised on. Assume first of all the a trusted entity keeps hold of
> legitimate public-keys for the users Alice and Bob. Here is how they agree
> on a key and authenticate:
Martin Hellman's name contains two `l's.
> 1. Alice and Bob, before the protocol has started have agreed on a
> generator, g, and prime, p for Diffie Helman.
>
> 2. Alice picks a random number 'a', and computes A=g^a mod p. Alice signs A
> with her private key.
... and sends the signed message to Bob. (You should practice being
precise in your protocol descriptions.)
> 3. Bob receives Alice's integer, A signed with her key. He retrieves her
> public key from the trusted database and confirms that A was indeed signed
> by Alice. Bob generators a random number 'b' and computes B=g^b mod p. Bob
> signs b with his private key.
I assume you mean that he signs B with his private key. He's not (I
hope) giving b to anyone. I also assume that he sends the signed B to
Alice.
> 4. Alice receives Bob's integer, B signed with his key. She retrieves his
> public key from the trusted database and confirms that B was indeed signed
> by Bob. Alice then computes B^a mod p to recover the session key, k.
>
> 5. Bob computes A^b mod p to recover the session key, k.
>
> Any problems with this.. ?
Yes. Suppose that Eve somehow manages to discover Alice's secret a from
some old run of this protocol (by computing discrete logs, or running
the protocol with Alice and asking `merely out of curiosity' what her
secret was, or bin-diving, or whatever). Then she can impersonate Alice
to anyone else by replaying her signed message containing the
corresponding public value A.
To defeat this attack, you need some way of ensuring the freshness of
the messages. For example, Alice and Bob could exchange signed messages
containing both A and B. The messages should probably also contain the
names of the principals involved.
The new protocol looks like:
A --> B: g^a
B --> A: g^b, S_B(Bob, g^b, Alice, g^a)
A --> B: S_A(Alice, g^a, Bob, g^b)
which is an extra pass, but it's worth it. Oh, I'd use DSA rather than
RSA -- using a discrete-log signature system reduces the number of
assumptions upon which your protocol's security rests.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 24 May 2001 17:08:34 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>Well, his basic premise is that the people who are listened to - the
>people who are taken seriously - are the "crypto gods", because they
>preach the (flawed!!!) conventional wisdom, and everyone looks up to
>them.
Maybe
>
>Maybe there are some things about the conventional wisdom that need to
>be looked at, and some of the premises (really big keys, the algorithm
>being somehow unknown or variable) that amateurs keep bringing
>forwards have _some_ merit to them, even if the problems that can be
>pointed out in their proposals from the conventional viewpoint are
>also valid.
>
>Anyone with the slightest understanding of human nature, of course,
>would know that Mr. Scott's approach is hardly the way to get anyone
>to consider opening their minds and giving another point of view a
>hearing.
But Mr J. I already know when it comes to the written word I
can't match there skill. So I guess I go to the other extreme.
Maybe there are a few to stupid to understand what I write. But
then do I care if stupid people understand or what they belive.
I would rather have them write me off. But there will be some bright
people who will look at what I am saying in spite of the poor words.
The people that can understand without specail catering to flowery
language in my view are better people in the first place. Maybe
its 26 years working for Sam. But I noticed the guys with the ties
where the ones most full of shit. Those that seem to know drank
beer and wore clothes just so they would not get arrested. But
then my career was at a unique place where at one time the job
was to get things working. i don't think thats the case today.
Thats also way I think time is on the Chinese side. We are not
making much really new. It more about bullshit knowadays. If the
chinese learn from all the stuff they bought from Bill. We may
get the shit kicked out of us in the next war. Yes there will be
a next war. If you know anything abuot history and I fear we will
not be ready. Much of the reason we wont be ready is due our
current government trying to hold everybodys hand. I will state
again make drugs free so idoits can OD on them. Let the weak cull
themselves.
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: Paul Rubin <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: 24 May 2001 10:21:48 -0700
"Harris Georgiou" <[EMAIL PROTECTED]> writes:
> I'm currently working on some distributed medical image analysis &
> diagnostic system and I was wondering: what security issues (if any) are
> addressed by modern medical LAN/RDBMS systems used by hospitals or
> insurrance companies? I mean, since most of these systems run over open
> TCP/IP networks (even the Internet), how does the confidentiality and
> intergrity of personal medical info is ensured?
The book "Security Engineering" by Ross Anderson has a number of words
on this subject.
------------------------------
From: Ian Stirling <[EMAIL PROTECTED]>
Subject: Re: Questionable security measures (Cloakware!)
Date: Thu, 24 May 2001 17:50:46 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
>"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Tom St Denis <[EMAIL PROTECTED]> wrote:
>>
>> > Leader in signature recog? They are the only ones stupid enough to
>> > try it. It's not hard to forge a signature, especially a hand written
>> > one.
>> It's not that easy. Note that traditional signature forgers only need
>> to create a static forgery -- i.e., one that looks right on the paper --
>> whereas to fool a biometric signature analyser, you have to create a
>> dynamic forgery -- i.e., the pressure, speed, order of the strokes have
<snip>
>> Then again, I don't believe in biometrics: they're not secret, and
>> they're awkward to revoke. And you need a secure connection to a
>> trustworthy biometric device to be able to accept its answers; otherwise
>> you can just replay a previous conversation.
>All good points. Too bad you can't apply any of them to
>Cloakware/Signature.
They do, if you are using a palm.
If I can get hold of someones palm for a few minutes, and take a copy,
there are several ways I can crack your product, AIUI.
Brute-force using the signature modules output to the decoder.
Semi-brute-force, using software that tries many different ways to sign
a static signature sample.
"Here's a package, sign here please" Followed by replaying the signature
into an emulator.
Insert either a hardware or software bug, to log signatures, and then
either record them, or beam them using IR.
Hardware or software that does a screen capture every few seconds when your
app is running.
--
http://inquisitor.i.am/ | mailto:[EMAIL PROTECTED] | Ian Stirling.
===========================+=========================+==========================
Lord, grant me the serenity to accept that I cannot change, the
courage to change what I can, and the wisdom to hide the bodies
of those I had to kill because they pissed me off. - Random
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 24 May 2001 17:53:37 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Only if your using a classical OTP. In this case you choose to limit
> yourself to only 2 messages. So if the enemy knows that there are
> normailly 1000 messages that you send. But through knowing how you
> implimetend your OTP. He could learn that a C = 1 is going to be
> 1 of two mesages. He could easily thtrough traffic analysis and knowing
> it only 1 of two possible messages. Limit that set to two values.
> Thats limiting it quite a bit.
You restated the obvious like three times. "limit yourself to only 2
messages...", "he could learn that C=1 is going to be 1 of two ..." and
finally "Limit that set to two values, thats limiting quite a bit".
> Far more secure would be if the change in encryption key that
> produced a 1 bit output. Could have been any one of the common
> 1000 messages in your set. Why let the enemy know that he has
> only two choices. IF you change your key every message. Your still
> telling him that it was message 0 or message 1. The OTP would give
> little security in the example you provide.
Um a single bit plaintext can only deliver two messages. 0 or 1. If you
are sending "Invade Normandy" obviously you are going to need more than a
single bit (unless poor Normandy was a chosen known target and 0/1 meant
attack or not attack).
You still restate the obvious. Of course there are only two possible
messages. That's a given. The problem you must solve is which one is the
correct one.
And I think you are starting to argue that the OTP is not secure... you
won't win alot of points with that argument.
> >> If you encrypt one byte with BICOM you most likely will
> >> get several bytes out. However if you did get one byte
> >> out the input file could be far more than one byte. This
> >> is beacuse if the key is not known many many thousands of
> >> different possible input files could have mapped to that
> >> single one byte output file.
> >
> >Ok bud, there is more to the world than "encryption". BICOM as I
> >pointed out earlier is vastly inefficient as compared to CTR modes and
> >as you have failed to point out not any more secure.
>
> Yes timewise BICOM is vastly inefficient to CTR mode
> but that does not make it less secure. If anything assuming
> one does all one can to opitmize the function it would make
> it more secure. The example of a one byte message being any
> of thousands instead of 256 should even show in your young
> and hopefully no fully brainwashed mind that its more secure.
Um you haven't shown that it's more secure. It's jsut different. Don't you
get that? Just because you say so doesn't make it true.
Prove us wrong in that CTR is secure. You're understanding of information
theory seems to be very lacking. Having one plaintext map to many
ciphertexts under the same key is not a feature desired by alot of systems.
> >
> >Besides BICOM can't be a "bijection" if one input maps to several bytes.
> >Let's say a 1 byte file maps to 3 bytes. Now to be fully bijective you
> >must map all 3 byte files to 1 byte. However that's not an invertable
> >function. So basically you do 1=>3 but out of the 2^24 possible 3 byte
> >files only 2^8 of them occur.
>
> Again you don't understand the concept. Your example if a one byte
> file maps to a three byte file ( with a given key). Then I say
> unto you that when you decrypt the file with the same key that
> 3 byte files maps back to that 1 byte file. There is no requirement
> that all 3 byte files map to one byte files. However if your
> alloed to seach full key space. I am sure that any 3 byte file could
> map to a one byte file on decryption if one found the key or keys to
> do it.
>
> The bijective Matt and I are talking about. Is the mapping of
> every binary file to every binary file. No gaps. Every file is
> encryptable with any key. And every file is decryptable with
> every key. There is no requitement that any given length most
> map to a given length. If there was then security would be weakened
> as in your weak CTR mode.
"your weak CTR Mode". First off I didn't propose CTR. Second why are you
calling it weak? Just because it doesn't have a feature you want? CTR has
a lot of benefits REAL people want.
I mean I have to believe you are joking because nobody is this stupid. Walk
into a broadcasting company and say "I have this new transform that a single
error destroys the entire stream..." They will laugh you out so quickly
that it will be funny. Or imagine cell phones that drop entire
conversations when a single bit is lost (actually your BICOM stuff is only
good for files... not streams).
CTR has alot of benefits you are overlooking or just don't care to think
about. There is more to crypto then some stupid block cipher. You have to
have real pratical systems.
Tom
------------------------------
** 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
******************************
