Cryptography-Digest Digest #430, Volume #14 Fri, 25 May 01 11:13:01 EDT
Contents:
Re: ECB plus padding instead of CBC? (Tim Tyler)
Re: Best, Strongest Algorithm (Tim Tyler)
Re: Best, Strongest Algorithm (Mark Wooding)
Re: Great Free Encryption Software (Mark Wooding)
Re: Information hiding in digital TV some thoughts and experiments. (Jan Panteltje)
Re: Protocol for authentication and key agreement... ("Simon Johnson")
Re: Evidence Eliminator works great. Beware anybody who claims it doesn't work
(propaganda) ("John Niven")
Is Rijandael = AES ? ("Christian Schindler")
Re: Is Rijandael = AES ? (Mark Wooding)
Re: Is Rijandael = AES ? (John Savard)
Re: ECB plus padding instead of CBC? (Roger Fleming)
Re: Medical data confidentiality on network comms ("Harris Georgiou")
Re: ECB plus padding instead of CBC? (John Savard)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 25 May 2001 10:18:32 GMT
Julian Morrison <[EMAIL PROTECTED]> wrote:
: "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
:> Assuming that you are looking at datagrams of no more than 4 Rijndael
:> blocks at a time, I believe your mode to be the best for your situation.
: Where did "no more than 4 Rijndael blocks" come from?
After 3 Rijndael blocks per datagram, you can send a 128 bit
IV at the-same-cost-or-less as your 25% random padding scheme.
:> Since you expressed that you need to know what the number of the block
:> was you might instead consider changing the last 32-bits (or however
:> many bits you would need) to a counter,
: Actually this built in counter effect is a big plus for the count mode.
: But you couldn't turn the cruft-padding into count-padding, that way it
: would be predictable and hence useless or at least very much weaker.
If you have a packet number available I would use it.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm
Reply-To: [EMAIL PROTECTED]
Date: Fri, 25 May 2001 11:41:34 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
[BICOM vs Rijndael in CTR mode]
:> It certainly has some different properties - here is some of the upside:
:>
:> * Use of the same key on different messages is much better with BICOM, due
:> to the whitening.
: I can use the same 128-bit AES key for the rest of my life and not
: compromise a CTR based system.
Well, perhaps you can - if you're prepared to transmit your counter
with each message - or if you are only talking to one person, and can
ensure none of your messages will be lost so you can keep in step.
:> * Bitflipping produces a huge error extension in BICOM - but none in
:> counter mode.
: This is NOT a feature of most applications. Think of a multimedia stream
: that gets completely and forever garbled because 1/2500 of a second was
: damaged....
Well, such data would be transmitted in chunks. It's likely to be
compressed /anyway/, so there's already going to be some error extension.
:> * BICOM compresses - files should be smaller, so there's less cyphertext
:> for the attacker to look at and messages are brought closer to the
:> unicity distance, so the likelihood of multiple correct-looking decrypts
:> is increased.
: Ah, but the avg. joe will use deflate (or mpeg, or ...) before encrypting
: too. This is not a feature that CTR based system couldn't share.
BICOM is Rijndael plus a compressor. Other Cypher/compression
combinations could equal it. If I were designing such a system,
I would be unlikely to use CTR mode. The benefits of counter mode
are counteracted by use of compression. The downsides of counter
mode - e.g. the necessity of keeping track of a counter - remain.
:> : 4. CTR is provably as secure as the underlying block cipher (assuming
:> : the keys are all random).
:>
:> How is this an advantage over BICOM?
: Um well BICOM is not provably secure as the block cipher. I would consider
: CTR to have the advantage.
Is this in the same way that CTR mode has an "advantage" over CBC mode?
:> : Yes, Bicom provides other things such as "bijectiveness" (which is the
:> : entirely wrong word when talking about a block cipher).
:>
:> BICOM is not a block cypher.
: I realize that. But when talking about ciphers (say in the same sentence)
: saying "non-bijective" is a bad idea.
"Most types of padding used in association with modern cyphers result in a
non-bijective map between the space of possible plaintexts and the
space of possible cyphertexts."
:> : Further more problems with BICOM
:>
:> : 1. No proof of security.
:>
:> No proof for CTR mode either.
: Um yes there is. If you had ever care to read up.
Both depend on a proof of security for Rijndael - which doesn't exist.
:> : 2. Not provably more secure then CTR mode
:>
:> That depends on the assumptions and the attack model somewhat. If BICOM
:> compresses the target text - and brute force is the best attack - it will
:> be provably more secure than counter mode.
: Why? Compressing stuff doesn't really make it any more secure. It just
: makes the ciphertext smaller.
It means the length of the cyphertexts is brought closer to the
unicity distance, increasing the liklihood of multiple possible
correct decrypts.
:> : 5. Not suitable for low end processors
:>
:> You mean it's /slightly/ more complex than Rijndael itself? That is true.
: If it involves arithmetic encoding I doubt you would covince a developer for
: a 8051 to use it. CTR involves xors...
BICOM is a file compressor - among other things. The target applications
are not the same as Rijndael.
--
__________
|im |yler http://rockz.co.uk/ http://alife.co.uk/ http://atoms.org.uk/
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Best, Strongest Algorithm
Date: 25 May 2001 12:59:07 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
> It certainly has some different properties - here is some of the upside:
>
> * Use of the same key on different messages is much better with BICOM, due
> to the whitening.
> * Bitflipping produces a huge error extension in BICOM - but none in
> counter mode.
Useless. If you want to detect tampering, use a MAC. If you don't, you
probably want minimal error extension.
> * BICOM compresses - files should be smaller, so there's less cyphertext
> for the attacker to look at and messages are brought closer to the
> unicity distance, so the likelihood of multiple correct-looking decrypts
> is increased.
So do gzip, bzip2 and so on. Using a cipher with a compression
algorithm is common practice.
Your problem is that you're actually using a really strange attack
model. You're assuming that the best attack against the cipher is
actually brute-force search of the keyspace, with unknown plaintext.
This smells unreasonably optimistic to me.
> No proof for CTR mode either.
What? You must have been dreaming. There's a proof that attacking CTR
under the real-or-random model is only `a bit' harder than
distinguishing the block cipher from a random function (where `a bit' is
carefully quantified).
Quoting Goldwasser and Bellare:
: Suppose F: { 0, 1 }^k x { 0, 1 }^l --> { 0, 1 }^L is a PRF and let
: R-CTR^F = (K, E, D) be the corresponding randomized CTR symmetric
: encryption scheme [...] Then for any t, q, \mu with \mu < L 2^l we
: have
:
: InSec^{se-ror} (R-CTR^F; t, q, \mu) <=
: 2 InSec^{prf}(F; t', q') + {\mu (q - 1) \over L 2^l}
:
: where t' = t + O(\mu) and q' = \mu/L.
In the above, t is the time available to the adversary, q is the number
of queries to the real-or-random oracle, and \mu is the number of
plaintext bits in these queries. InSec^{test}(F; resources) is the
maximum advantage for any adversary with the stated resource bounds
participating in the given test.
The real-or-random test consists of providing the adversary with an
oracle which returns the ciphertexts of /either/ the plaintexts given to
it, /or/ randomly chosen plaintexts of the same length; the adversary
has to return which it thinks the oracle is doing. The advantage of the
adversary is (twice, for complicated reasons) the difference between its
probability of success and 1/2.
The PRF test consists of giving the adversary an oracle for either a keyed
instance of the given function or a random function, and having it guess
which.
(By starting your counter where you left it last time, you can lose the
{\mu (q - 1) \over L 2^l} term.)
This is an extremely important result, as I'm sure you can realise.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Great Free Encryption Software
Date: 25 May 2001 13:18:43 GMT
George Peters <[EMAIL PROTECTED]> wrote:
> Wow! Nothing like good old DOS commands. Talk about cutting edge
> technology. I guess these guys haven't heard about OOP yet.
> I do have to point out at least their documentation is pretty good about
> concepts in cryptograhy, as far as public key is concerned.
Why just have one non-sequitur when you can have three? I don't see why
whether a program hsa a flashy GUI has any bearing on how clever it is
inside. And I don't see why object oriented programming has any
relevance to either.
Hmm. I must be losing it: I'm picking an argument with a spammer.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Jan Panteltje)
Subject: Re: Information hiding in digital TV some thoughts and experiments.
Date: Fri, 25 May 2001 13:27:57 GMT
On a sunny day (Thu, 24 May 2001 03:18:27 GMT) it happened Ian Stirling
<[EMAIL PROTECTED]> wrote in
<[EMAIL PROTECTED]>:
>Jan Panteltje <[EMAIL PROTECTED]> wrote:
>>Digital TV transmissions are now common in Europe.
>>With a small dish one can receive 400 or more stations, some encrypted, some
>>not.
>>Recently I have been involved with processing this digital information,
>>in my case mainly to write software that allows one to add / edit subtitles to
>>existing programs.
>>In experimenting I discovered the digital transport stream as used in DTV is a
>>place with a vast potential to hide any info you like in any way you like,
>>with a huge bandwidth too.
>
>>For example small changes (say the last few bits) in the PTS (presentation
>>time stamp, used in PES (program elementary stream) packets) (and perhaps even
>
>This is the barest fraction of the possibilities.
>For example, the recievers have to cope with maybe (guessing) 1/10th of
>the raw bits being in error, and do error correction before recovering
>the MPEG stream.
>
>If 1% of the bits sent are instead not errors, but an encrypted datastream,
>then even sending live video streams is possible.
>
Perhaps a high error rate combined with a strong signal would be
percieved as suspicious?
Out of signal strength, carrier presence, Viterbi, sync carrier, some things
can already be deduced, and that is even displayed on the receiver.
Maybe it is there indicated as 'quality'.
A low quality combined with a high signal strength is suspicious IMO.
This is the status definition for the video for Linux header:
(I am using Technotrend DVB card on Linux for reception, see
www.convergence.de linux-tv, the links for driver development etc).
/* status information */
int fsync; /* frequency sync (from tuner) */
__u32 curfreq; /* frequency which is actually used, e.g. after AFC */
int sync; /* sync from decoder */
#define DVB_SYNC_SIGNAL 1
#define DVB_SYNC_CARRIER 2
#define DVB_SYNC_VITERBI 4
#define DVB_SYNC_FSYNC 8
#define DVB_SYNC_FRONT 16
__s32 afc; /* frequency offset in Hz */
__u16 agc; /* gain */
__u16 nest; /* noise estimation */
__u32 vber; /* viterbi bit error rate */
int flags;
#define FRONT_TP_CHANGED 1
#define FRONT_FREQ_CHANGED 2
#define FRONT_RATE_CHANGED 4
};
Note the viterbi bit error rate.
Some playing around with these may perhaps give some indication about
'abnormal' conditions.
I do agree with you that in spite of all this there is plenty of room to
play.
Regards
Jan
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Protocol for authentication and key agreement...
Date: Fri, 25 May 2001 15:06:42 +0100
Mark Wooding <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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.
Thanks.. my spelling is great :\
>
> > 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.)
Yup.. i don't have much practice at writing protocols.. this is the
practice =)
> > 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.
Once again.. u pointed out a fatal mistake... thank you again.
> > 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.
Cool.. that's something to consider... thanks again.
Simon.
> -- [mdw]
------------------------------
From: "John Niven" <[EMAIL PROTECTED]>
Crossposted-To:
alt.privacy,alt.security.pgp,alt.security.scramdisk,alt.privacy.anon-server
Subject: Re: Evidence Eliminator works great. Beware anybody who claims it doesn't
work (propaganda)
Date: Fri, 25 May 2001 15:02:00 +0100
I've been alerting [EMAIL PROTECTED] - here's their reply:
<< begin >>
Hi John -
Thanks for your recent email.
We are currently investigating a series of complaints relating to this
issue. Please rest assured that once our investigations are complete
that the appropriate action will be taken.
Regards,
Mike White
Acceptable Use Policy Team
ntl: Technology. Tamed.
http://www.ntlworld.com
<< end >>
John
--
John Niven
(Reply through newsgroup)
"Eric Lee Green" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >>Thought this was just another forged post, but look at the headers.
Posted
> >>from ntl in Nottingham. Actual official spam.
> >>
> >[Shaun in alt.security.scramdisk]
> >
> >If anyone can Email me their address I'll drive down to Nottingham and
> >tell them what I think.... EE had a fine reputation..... Which is now
> >in tatters... Destroyed by those whose interests I would have thought
> >would have been to protect it.
>
> Their address is public record. It is on their incorporation papers,
> which another UK citizen helpfully mailed to me (what, you don't think
> *I* care enough about these spamming fools to pay for a copy, do
> you?). I can't re-post those incorporation papers because they are
> under Crown copyright, but I can definitely post the info from those
> papers, including who the two principals are, their date of birth, and
> their address. See:
>
> http://badtux.org/eric/editorial/scumbags.html
>
> for the package.
>
> PS: They also said that Scramdisk has a back door in it. I'm sure that
makes
> YOU happy!
------------------------------
From: "Christian Schindler" <[EMAIL PROTECTED]>
Subject: Is Rijandael = AES ?
Date: Fri, 25 May 2001 16:10:13 +0200
Hello,
Is the Rijandael-algorythmus the same as AES??
Regards
Christian
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Is Rijandael = AES ?
Date: 25 May 2001 14:26:37 GMT
Christian Schindler <[EMAIL PROTECTED]> wrote:
> Is the Rijandael-algorythmus the same as AES??
Not yet. But it will be.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is Rijandael = AES ?
Date: Fri, 25 May 2001 14:27:57 GMT
On Fri, 25 May 2001 16:10:13 +0200, "Christian Schindler"
<[EMAIL PROTECTED]> wrote, in part:
>Is the Rijandael-algorythmus the same as AES??
Yes.
Just about.
Several algorithms were submitted to NIST, and of them, Rijndael was
chosen for the standard.
However, Rijndael _as submitted_ is not the standard itself, but the
basis for the standard. The official Advanced Encryption Standard has
not yet been issued.
One difference that is currently anticipated to exist between Rijndael
as submitted and the standard as eventually issued is that Rijndael as
submitted included provision for block sizes of 128, 160, 192, 224 and
256 bits, and key sizes of 128, 160, 192, 224, and 256 bits, it is
likely that the official standard will only provide for a block size
of 128 bits and key sizes of 128, 192, and 256 bits.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (Roger Fleming)
Subject: Re: ECB plus padding instead of CBC?
Date: Fri, 25 May 2001 13:35:58 GMT
"Julian Morrison" <[EMAIL PROTECTED]> wrote:
[...]
>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.[...]
Well, there are good paranoid reasons for changing the key from time to time
anyway:
- minimizing data encrypted under one key
- limiting the damage done by key compromises
- reducing the "exposure time" during which a key must be protected
Because of these, it is usually recommended you change your key as often as is
convenient. For a fast networked computer, several times a day is not
unreasonable.
To change keys automatically without the risk of MITM attacks you need a key
agreement or key exchange protocols, and there are lots of complex ones to
look at on the net. One of the most complete is STS (station-to-station)
protocol, also called "authenticated Diffie-Hellman". One of the simplest and
most elegant is SPEKE.
If you don't have the resources to run all that public key stuff (or just
can't be bothered coding it), there's still some symmetric algorithms to look
at, although their security guarantees are generally less sweeping. For
example, from SKIP (part of IPSEC) comes the Zero Message Master Key Update
protocol, which is basically
kK_n = h(K | n) (done simultaneously at both ends)
where k_n is the n'th message key, K is a master key, | is concatenation, h is
a hash function, and n is a counter. In ZMMKU, K is 256 bits, although for
most hashes there is no reason it couldn't be up to 480 bits. (Actually, the
official version of ZMMKU is a little different, simply to widen the output of
their hash). Personally, I'd like something like
k_n = h(K | k_(n-1) )
which seems to do everything ZMMKU does but adds forward secrecy at no cost.
What does this give you? First, with any decent hash function, it's so fast
you can do it a hundred times a second if you really like. Second, the
relation between message keys is so complex there is no risk of related key
attacks. Third, unless the opponent can obtain the master key (by brute force,
theft of the computer, or the ability to invert hashes), no number of message
keys he obtains, by whatever means, will help him obtain any other message
key. Fourth, even if he does somehow obtain the master key and at least one
message key, he can only work forwards; all your old messages are safe. This
is pretty good for such a simple function.
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Fri, 25 May 2001 17:51:33 +0300
� Kathleen Chapman <[EMAIL PROTECTED]> ������ ��� ������ ���������:
%WiP6.1808$[EMAIL PROTECTED]
> > 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?
>
> Harris,
> I didn't catch your original message, but if organizations in the United
> States may be using your application, it's got to meet HIPPA security
> requirements. HIPPA stands for Health Insurance Portability and
> Accountability Act. One part of it is to set national standards for
> electronic transmission of claims, enrollment, eligibility, payment, and
> other information. Another part is to set standards for the security of
> health information systems. Here is a link to the Information Technology
> Association of America's HIPPA page:
> http://www.itaa.org/isec/ehealth/hippa.htm
>
> Kathy
My application is purely an academic research project for now, but I will
take a look at HIPPA requirements - I think it is exactly what I was hoping
for.
Thanks :))
--
Harris
- 'Malo e lelei ki he pongipongi!'
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: ECB plus padding instead of CBC?
Date: Fri, 25 May 2001 14:59:49 GMT
On Tue, 22 May 2001 22:09:06 +0100, "Julian Morrison"
<[EMAIL PROTECTED]> wrote, in part:
>Will this work? I have a block cypher, say Rijndael, which has an input of
>16 bytes. I use the first 12 of those bytes for data and fill the last
>four from /dev/urandom.
>The intent is to avoid CBC, so that any 16 byte data chunk can be
>separately decoded despite missing data chunks.
>Is this a good approach? What security do I lose from this (if any)?
A similar approach was originally used with IBM's LUCIFER cipher.
You don't lose security, but you do lose bandwidth.
If you did use CBC, and had a missing block, you would only lose that
block and the one immediately following, but you would still be able
to decode all remaining blocks. So this is what is usually done, and
losing bandwidth in this way is avoided - instead of throwing away 25%
of bandwidth, you merely lose two blocks instead of one when there is
a problem with one block.
Also, you have 128 bits of randomness, rather than 32, ensuring
different encipherments of the same block are different, which is
desirable, even though the basic security is the same.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
** 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
******************************
