Cryptography-Digest Digest #423, Volume #14 Thu, 24 May 01 11:13:01 EDT
Contents:
Re: 1st CipherText Application prototyped ("Prichard, Chuck")
Re: New type of cryptanalysis ("Simon Johnson")
Protocol for authentication and key agreement... ("Simon Johnson")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Medical data confidentiality on network comms ("Harris Georgiou")
DES Algorithm (Ralph Hofmann)
Re: Protocol for authentication and key agreement... (Mark Currie)
Re: New type of cryptanalysis ("Douglas A. Gwyn")
Re: survey ("Douglas A. Gwyn")
Re: Small (not fast) RIPEMD-160 (jlcooke)
Re: Medical data confidentiality on network comms (jlcooke)
acceptance of encryption, market research (LLCoolLok)
Re: Ideas for project (Simon West)
Re: survey ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: 1st CipherText Application prototyped
Date: Thu, 24 May 2001 12:00:22 GMT
A demonstration copy of the initial prototype can be downloaded at:
www.greentv.com/CipherText/CipherText.ZIP
-Charles Prichard
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: New type of cryptanalysis
Date: Thu, 24 May 2001 13:29:17 +0100
David Wagner <[EMAIL PROTECTED]> wrote in message
news:9eh9mf$3eu$[EMAIL PROTECTED]...
> Are you aware of the work on interpolation attacks?
Yah.. u told me about this attack.. though I neglected to read about the
attack..
in fact it was the name that gave me the idea... =)
So, I take it the two attacks are identical?
oh well, I suppose its encouraging to see that line of attack independently
I guess... I'll look at the paper.
Simon.
Simon.
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Protocol for authentication and key agreement...
Date: Thu, 24 May 2001 13:45:06 +0100
This is a protocol I will be placing in a home brew networking program. I've
put it on here to see if anyone can point out any mistakes I might have
made.
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:
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.
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.
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.. ?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 24 May 2001 12:43:31 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<tl5P6.23914$[EMAIL PROTECTED]>:
>> >> >> And you never anwsered the FACT that a one byte ouput file
>> >> >> from CTR mode (though you have no working program) would
>> >> >> imediately lead an attacker to realize that the input file could
>> >> >> only have come from 1 of 256 possible messages. With BICOM you
>> >> >> have many many more messages. That alone makes it more secure.
>> >> >> Or do you have the ability to even understand this fact. Both
>> >> >> methods use RIJNDEAL as the underlying model. One just does it
>> >> >> in a better way. As I pointed out above. I would rather confuse
>> >> >> the enemy with many possible messages than just 256 messages.
>> >> >>
>> >> >
>> >> >That's entire BS. If the plaintext is uniformly distributed then
>> >> >CTR
>> >>
>> >> Well I see you can't anwser the above want to try again.
>> >
>> >What the F#CK are you yacking about? a 8-bit message can only map to
>> >8-bit outputs to be bijective (well not entirely). CTR mode is just
>> >a bloody xor of some random bits against a message. How can that
>> >possibly be less secure than BICOM?
>> >
>> >Want me to write a program that uses the CTR mode?
>>
>> Only if your willing to look at what BICOM does. You
>> seem to only habd wave. You have never looked at it or
>> tested it.
>> Yes CTR being less secure can only map one BYTE to one
>> BYTE. But bijective BICOM is not that weak. Why would
>> anybody want a one byte file to map to one byte when
>> it would means there are only 256 possiblilites for input
>> messages.
>
>Because if you knew anything about information theory that's all you
>need.
>
>Here's an OTP encrypted message.
>
>C = 1
>
>What is the plaintext? You will never know. P is either 1 or 0, but
>you can't tell.
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.
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.
>
>
>> 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.
>
>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.
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: "Harris Georgiou" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Medical data confidentiality on network comms
Date: Thu, 24 May 2001 16:16:41 +0300
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: Ralph Hofmann <[EMAIL PROTECTED]>
Subject: DES Algorithm
Date: Thu, 24 May 2001 15:29:38 +0200
Hi there,
I need a DES coded in 16-bit Intel assembler for performance reasons.
Anybody out there who can point to a proper resource?
TIA Ralph
------------------------------
Subject: Re: Protocol for authentication and key agreement...
From: [EMAIL PROTECTED] (Mark Currie)
Date: 24 May 2001 14:11:31 GMT
Hi,
This is basically the signed DH protocol and is pretty good. The advantage is
that it can be done with only two exchanges (can even be full-duplex). However,
with very little overhead you could extend this to something like STS. This
will give you mutual key authentication and prevent some types of protocol
attacks. One of these is a Denial Of Service (DOS) attack by simply replaying
an old exchange value. Data will decrypt into junk and you will not be able to
tell why. Another would be if one party's random number is ever compromised,
then the attacker can masquerade as that party by re-using the corresponding
exchange value. The masquerade can be continued with anyone else on the network
until the compromised party's certificate expires. The protocol must have a
binding function which ties exchanges together so that they can never be
re-used.
Mark
In article <9eivde$4pk$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>
>This is a protocol I will be placing in a home brew networking program. I've
>put it on here to see if anyone can point out any mistakes I might have
>made.
>
>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:
>
>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.
>
>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.
>
>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.. ?
>
>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New type of cryptanalysis
Date: Thu, 24 May 2001 14:00:01 GMT
Simon Johnson wrote:
> I call it "polynomial analysis"...
Generally speaking, the more parameters of a model you can fit
to the data, the more accurately you can approximate the actual
behavior, unless the model is totally inappropriate. There are
some powerful general tools that can help analyze data when a
(multi)linear model is used, e.g. Fourier analysis, which aren't
very helpful for nonlinear models.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Thu, 24 May 2001 14:01:56 GMT
Mok-Kong Shen wrote:
> I think that basically you are favouring a good well-
> coupled combination (unification/synergy) of stream and
> block processing techniques (in the common terminology).
About the only block-like thing in general stream ciphers
is that they have a finite amount of internal state, e.g.
in a simple system it might be contents of a shift register.
------------------------------
From: jlcooke <[EMAIL PROTECTED]>
Subject: Re: Small (not fast) RIPEMD-160
Date: 24 May 2001 14:12:32 GMT
I've got RIPEMD160 to 1990bytes. SHA-1 to 1360bytes.
Ian Stirling wrote:
> Yes. Well, no. Well, it's the tool that is widely used AIUI to setup
> loopback devices with encryprion, so if you want to use the same password
> before and after install, then it needs to be RIPEMD-160
I can't see how ripemd160 vs sha1 would be different here. They act the
same way.
I'll be glad to donate the implementation as a contributor. What's the
name/location of the project? Sourceforge or is it a Kernel work group?
JLC
------------------------------
From: jlcooke <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: 24 May 2001 14:21:31 GMT
You'll find that doctors don't want thing to slow them down. That will
lead to the creation of security issues. My suggestion: don't store
ANYTHING - in memeory or otherwise - unencrypted. Put timed self
destruction features all over the place.
The crypto will be the same as usual.
JLC
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] (LLCoolLok)
Subject: acceptance of encryption, market research
Date: 24 May 2001 07:46:22 -0700
hello,
i wonder if there has been a research done concerning the acceptance
of encryption.
for example, what do people cite as the main reason for using
encryption, and (what i am interested in) what do people cite as the
main reasons for NOT using encryption. ease of use will probably score
high.
anyone knows of a previous research?
regards,
lokman tsui
university of leiden
------------------------------
From: [EMAIL PROTECTED] (Simon West)
Subject: Re: Ideas for project
Date: 24 May 2001 07:50:17 -0700
Thanks for everyone's input.
Regarding Paul Rubin & Jeffrey Walton's comments:
To be honest considerations of patent, release as free software etc had not
entered my mind.
As far as I am concerned I am perfectly happy to release the results
of any work that I produce. All results and source code will be
detailed in my thesis and would be in the public domain anyway and I could
make it available via a web site for those interested.
Suggestions and ideas from other parties will be acknowledged in the thesis.
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.
Regarding Tom St Denis's comments:
Don't know what ideas Paul has further to the baby PGP
clone that you suggest, sounds like a good starting point,
but you are quite write two months is not a lot of time to
work with. I am in the middle of a crop of exams at the moment
but from the top of my head I seem to recall the PGP is
asymmetric and based on the Diffie-Hellman algorithm?
Not too sure what is involved in the writing and breaking
of cryptosystems as, you will guess, I am a bit of a novice.
How would this help towards an application?
Look forward to hearing more,
Regards,
SIMON WEST
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Thu, 24 May 2001 14:09:23 GMT
Tom St Denis wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > Tom St Denis wrote:
> > > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > > > Tom St Denis wrote:
> > > > > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > > > > > Tom St Denis wrote:
> > > > > > > Well my design is simple and faster than most other known block ciphers.
> > > > > > > Does that count?
> > > > > > No.
> > > > > > void encrypt(const char *key, char *data) { } // very fast and simple
> > > > > And you call me immature? Wow, you guys have high standards... double
> > > > > standards but high none the less.
> > > > I was making an important point. I'm sorry you missed it.
> > > I posted a complete algorithm and rough paper to talk about the decisions I
> > > made.
> > > Your reply was just immature and a poke. Sorry, what did I miss?
> > Think about it. I too posted a complete algorithm.
> > I didn't write a "rough paper" about it because it
> > is simply a counterexample to the idea that being
> > simple and fast gives the design merit.
> Fine be a jackarse.
> You're not proving anything other than you have an insane ability to argue
> irrelevent semantics.
> My designs are actually based on some stuff I observed. I am trying to
> learn stuff. I can't do it alone though. Foolish me to think others will
> want to willingly help instead of use their time to belittle others. How
> big you must feel. Bravo.
Either you refuse to try to understand, or you don't understand
the role of counterexamples in reasoning. Either way, you lose.
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".
------------------------------
** 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
******************************
