Cryptography-Digest Digest #747, Volume #12 Fri, 22 Sep 00 14:13:01 EDT
Contents:
Re: Tying Up Loose Ends - Correction (Tim Tyler)
Re: State-of-the-art in integer factorization ("Sam Simpson")
Re: Tying Up Loose Ends - Correction (Tim Tyler)
Re: Tying Up Loose Ends - Correction ("Trevor L. Jackson, III")
Re: State-of-the-art in integer factorization (JCA)
Re: Dr Mike's "Implementing Elliptic Curve Cryptography" - reader comment
(DJohn37050)
Re: IBM analysis secret. (DJohn37050)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
Re: Music Industry wants hacking information for cheap (Scott Craver)
Re: What am I missing? (Scott Craver)
Re: 3DES - keyoptions ("Neil McKeeney")
Re: t (rot26)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Reply-To: [EMAIL PROTECTED]
Date: Fri, 22 Sep 2000 14:04:26 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
:> : [EMAIL PROTECTED] (Benjamin Goldberg) wrote:
:> :>SCOTT19U.ZIP_GUY wrote:
:> :>> [EMAIL PROTECTED] (Mok-Kong Shen) wrote:
:> :>> >Tim Tyler wrote:
:> :>> >> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> :>> >> : If my message is over one hundred bytes, do you think
:> :>> >> : that I need to care about wasting 5 bits?? [...]
:> :>> >>
:> :>> >> At worst, this can reduce the size of keyspace by a factor of 32.
:> :>> >
:> :>> >Sorry, I don't understand. What do you mean by 'keyspace'
:> :>> >here? This is the message space. The message gets longer
:> :>> >by 5 bits. There is no information in the above of how
:> :>> >big the key is. [...]
:> :>>
:> :>> I thought we are talking about compressing then ecnrypting.
:> :>> If you always add 5 zeros or any other fixed amount of bits
:> :>> after a compressed string or any file for that matter which is
:> :>> then encrypted. The attacker know what the last few bits are
:> :>> and throws out keys that don't match. So if the last five bits
:> :>> of a file are known then it means you reduce your key space by
:> :>> 5 bits.
:> :>
:> :>Reducing the message space by x bits does *not* reduce the keyspace by x
:> :>bits... How much the keyspace is reduced depends on the unicity
:> :>distance.
[...]
:> If one was *replacing* five bits at the end of the message by 0s,
:> the effect would depend on the unicity distance [because those
:> bits might have been known already].
: No. [...]
I believe what I wrote was correct.
: Consider this: Encryption algorithm A encrypts, with
: a key K, blocks of 64 bits and produces ciphertext of
: same number of blocks of same lengths. Encryption
: Algorithm B uses the key K to do the same and append
: at the end 5 0's. [...]
That's different from replacing symbols at the end of
a message - which is what I said I was discussing.
: Now the ciphertext of algorithm B is longer than the ciphertext of
: algorithm A. Does that matter excepting the transmissin cost?
There's five "0"s worth of known plaintext.
: Where does the 'keyspace' play a role here at all?
The known plaintext allows you to reject keys. You might not otherwise
be able to do this, or might not be able to do it with such speed,
or certainty. This reduces the effective number of keys that need
to be considered in more depth. It might (or might not) make a
difference to the time taken to break the system.
:> That's not what David was talking about. David is discussing the
:> effect of adding an additional section of known plaintext to the
:> end of the file. This normally has the effect of decreasing the
:> keyspace by almost exactly five bits - provided the effective
:> keyspace doesn't go negative, of course.
: No. [...]
I think what I wrote was correct.
: He was criticizing my end-of-file symbol taking up extra bits. [...]
Yes. He also discussed the possible costs of reserving a symbol
for this purpose.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Breast is best.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: State-of-the-art in integer factorization
Date: Fri, 22 Sep 2000 15:21:58 +0100
Erm, RSA and DH equivalents were found by GCHQ prior to the public
disclosures. Your point was? ;)
Just because euro/asia crypt publish QS/NFS papers, how does this
reflect upon the abilities of NSA / GCHQ etc?
--
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:8qfefu$g2v$[EMAIL PROTECTED]...
> In article <8qedb0$c49$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Ed Pugh) wrote:
> > Bob Silverman ([EMAIL PROTECTED]) writes:
> > >
> > > Nothing has been written. Improvements have been only
incremental.
> > > (i.e. slightly faster machines, a few more percent squeezed
from
> > > code, etc.). There hasn't been a new algorithm in 11 years.
> >
> > Well, at least none that the NSA have let on about, anyway. ;-)
>
> That's right because the public open academia are just stupid
people.
> Not to mention that virtually all milestones in factoring were
public
> endeavours [sp].
>
> Try reading euro/asia crypt from about 81 to now and you will see a
> plethora of factoring papers, specially the QS, the NFS, and
various
> other methods I didn't know of till I read it.
>
> Tom
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Reply-To: [EMAIL PROTECTED]
Date: Fri, 22 Sep 2000 14:17:12 GMT
Gregory G Rose <[EMAIL PROTECTED]> wrote:
: TT wrote:
: <<<An alternative - which I've not seen discussed on this forum - would be
: <<<to use an encryption device which is capable of encrypting variable
: <<<length bitstrings, and is not confined to multiples of 8 bits. I
: <<<attribute this idea to David Scott.
: There is nothing new in this idea. [...]
I should clarify that the idea that I had not encountered before
David mentioned it to me was that of resolving the issue of compressed
data frequently requiring padding to reach a multiple of 8 bits - by
encrypting the data prior to transforming to a file.
I can't have been talking about DS inventing variable-length encryption -
since that idea is well known, is about as obvious as the notion of a
random permutation - and can be implemented with practically any Vigenere
cypher.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
------------------------------
Date: Fri, 22 Sep 2000 10:36:19 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Tim Tyler wrote:
> John Savard <[EMAIL PROTECTED]> wrote:
> :TT wrote:
>
> :>If you want to obscure the length of the file from your adversary, as
> :>much random padding as you like can be used at this stage.
>
> : False. If padding is added *after* encryption, one has to [...]
> : indicate where the padding starts in the clear so that decryption will
> : act on the right bits.
>
> I wonder if someone can help me here. I don't yet have clear views in
> this area.
>
> I would like to be able to articulate the criteria that a good packing
> scheme to be applied before encryption should have - assuming that a
> good random stream is available to do the padding with.
>
> It seems to me that the issue is non-trivial. I believe a packing scheme
> should be able to transform an arbitrary message into an arbitrary padded
> message, from which the recipient should be able to recover the original
> message unabmiguously - without any shared secret being involved.
>
> It should also minimise the number of decrypts that form "impossible"
> messages that can't possibly represent a padded message - for the same
> sorts of reasons that David likes compression not to allow keys to be
> rejected.
>
> I'm undecided about whether the padding should be added in one place,
> or should be distributed around in the hope of preventing attckers from
> matching known-probable plaintexts with message sections.
>
> I'm inclined to think that unkeyed transformations designed to thwart
> known partial plaintexts are mainly a separate issue from padding schemes
> - if you want to apply an AONT to help prevent known plaintext attacks
> that choice is available to you.
>
> Has this problem been studied? Are there padding schemes that do better
> than (say) prepending a self-terminating length field to the start of
> the message? This results in many "impossible" padded messages :-<
It may be useful to simplify the requirements by ignoring the padding issue.
This can be done by casting the problem as a mapping of input messages of
arbitrary bit length to output messages of integral byte (or word or block)
length.
*How* the mapping is performed depends on the handling of the oddness of the
input -- the padding. But a uniform mapping is optimal for the purpose of
shrouding the input.
A keyed uniform mapping can be as simple as a PRNG mask applied just prior to
the output.
------------------------------
From: JCA <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: State-of-the-art in integer factorization
Date: Fri, 22 Sep 2000 07:50:04 -0700
I thought this was common knowledge but in fact I have received several
email requests along these lines.
I got the paper from ftp://ftp.cwi.nl/pub/pmontgom. Peter Montgomery
himself appears in this forum every now and then, and I was hoping he
would have something new to contribute to this issue.
Jeffrey Williams wrote:
> Would the Montgomery paper happen to be available on-line? And if so, could
> someone please post a pointer to it?
>
> LL&P
>
> Jeff Williams
>
> Bob Silverman wrote:
>
> > In article <[EMAIL PROTECTED]>,
> > JCA <[EMAIL PROTECTED]> wrote:
> > >
> > > I've got Peter Montgomery's excellent survey on integer
> > > factorization
> > > algorithms. However, being as it is five years old now I was wondering
> > > if there is something more up to date out there. Or, at the very
> > least,
> > > and
> > > addendum to this paper.
> >
> > Nothing has been written. Improvements have been only incremental.
> > (i.e. slightly faster machines, a few more percent squeezed from
> > code, etc.). There hasn't been a new algorithm in 11 years.
> >
> > --
> > Bob Silverman
> > "You can lead a horse's ass to knowledge, but you can't make him think"
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Dr Mike's "Implementing Elliptic Curve Cryptography" - reader comment
Date: 22 Sep 2000 15:18:13 GMT
The smallest prime field in the NIST curves does happen to be larger than the
smaller binary field. And they are both rated at 80 bits. Certainly, some of
the selection process was due to percieved potential for performance.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: IBM analysis secret.
Date: 22 Sep 2000 15:22:48 GMT
Don Coppersmith wrote an article on DES published in the IBM Journal of
Research and Development when he says that IBM knew of the potential for
differential analysis (they had another name for it) and designed DES to resist
it. And that this info was kept secret, as they saw no reason to help an
adversary, as it was a powerful attack. He also listed all the security
criteria of the S- boxes.
Don Johnson
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Date: Fri, 22 Sep 2000 17:50:52 +0200
Tim Tyler wrote:
>
> I believe what I wrote was correct.
O.k. I take back what I said. But would you please
explain a bit why the keyspace is reduced by 32 through
the 5 0-bits in the input to encryption? I don't know
how to get that exactly. Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Date: Fri, 22 Sep 2000 17:50:48 +0200
"SCOTT19U.ZIP_GUY" wrote:
>
> No I was also in this and other threads criticizing the
> use of an EOF symbol in any huffman or arithmetic type of
> compression as nothing more than a means to make the following
> encryption weaher. Becasue it makes the effective key space
> smaller.
The eof is unknown to the opponent as well as the
random filling. For him that could just as well be
some sort of compressed 'plaintext', isn't it? Since
that corresponding 'plaintext' presumably has
less regularity than the proper plaintext, that
addition cannot be easier to deal with. The input
to encryption is longer and output also. But, as said,
that amount is negligible.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: Music Industry wants hacking information for cheap
Date: 22 Sep 2000 16:07:23 GMT
zapzing <[EMAIL PROTECTED]> wrote:
> These so called technological methods of protecting a copyright are the
> purest of fiction. At some point it must be converted into sights and o
> sounds so that a Human can enjoy them. At that point, just record it
> and copy it as much as you wish.
False! That's the whole point of audio watermarking: it's
not encryption. Even when the media is converted to "sights
and sounds" (i.e., unscrambled/unencrypted) and played on your
TV and stereo, the watermark is still hidden inside it.
At that point, if you try to record the audio, right from your
amp's line out into an SDMI-compliant recording device, the
device will still refuse to record it. Unless you strip out
the hidden signal, which for the time being requires a piece
of software which would be illegal to own or distribute.
>Unless if you think that they are going to put one of their DVD-whatever-
>things into every camcorder in the world. LOL.
Presumably, anything that records _onto_ a DVD from a line in
will have a watermark detector. I don't know what they will
try to do for other kinds of digital media such as DV tapes.
For a camcorder there shouldn't be a problem, unless the
camcorder has a line input rather than just a lens input.
If that sounds ridiculous, I can't disagree. But people who
control various patents can enforce compliance among device
manufacturers.
>Void where prohibited by law.
-S
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: What am I missing?
Date: 22 Sep 2000 16:26:38 GMT
Sagie <[EMAIL PROTECTED]> wrote:
>No, no, you got it all wrong...
You got it 90% right....
>SDMI is a *WATERMARK*, it is not an encrypted format.
SDMI is a security initiative for digital music that incorporates
watermarking, along with other stuff. Watermarking is important
for its security, because a main goal of the initiative is to
identify stolen music long after it's been ripped, and perhaps
converted to various formats.
Mr. Barber says that SDMI is intended to replace MP3 --- this
is not right. SDMI is not a format or codec, and an SDMI device
will play MP3s as well as WAVs. What it won't do is record
WAVs or MP3s that belong to Time Warner, etc.
Funny fact: SDMI does not just include inaudible "don't copy me"
signals, but also inaudible "don't copy me if I'm compressed,
or have ever been compressed in the past" signals. This is an
attempt to quash MP3 piracy in particular: you will be able
to rip a CD track into an SDMI device you can take jogging,
but not a downloaded MP3.
>Ryan was right in
>his observation -- SDMI's efforts are futile, because people can still
>listen to the music using "old" unprotected players, whatever the
>actual format is.
Mr. Barber was right in his observation --- compliant devices
can, if the recording industry plays its cards right, be the
only devices manufactured that will play new formats or new
compression codecs. They can become the "common case" players
that the kiddies get around X-mas.
The fact that you can always play the files on your computer,
or on older MP3 players, might not amount to much if player
technology really takes off and your old devices are left
in the dust.
>Ryan -- using an audio editor (e.g. Cool Edit, Sound Forge), try
>to "subtract" the original wave from the watermarked wave. This will
>allow you to see the actual watermarking signal and analyse it.
It will allow you to do the former but not the latter---that
takes signal processing know-how. But then again, you gain
that kind of know-how partially by experimenting with these
things.
Ryan, if you don't have an audio editor, you can just write
a computer program. The bytes of their WAV files consist of a
header you should ignore, then the string "data," followed
by a 4-byte number telling you how many bytes are in the
audio. After that, every 4 bytes contains two samples,
a 2-byte sample for the left speaker and a 2-byte sample for
the right. These are in signed little-endian notation, i.e. in C,
char buffer[4];
fread( buffer, 1, 4, input_file );
left = buffer[0] + buffer[1]<<8;
right = buffer[2] + buffer[3]<<8;
if( left>32767 ) left -= 65536;
if( right>32767 ) right -= 65536;
-S
------------------------------
From: "Neil McKeeney" <[EMAIL PROTECTED]>
Subject: Re: 3DES - keyoptions
Date: Fri, 22 Sep 2000 17:54:33 +0200
kihdip <[EMAIL PROTECTED]> wrote in message
news:8qck6q$2b4$[EMAIL PROTECTED]...
> What is the clever thing with key-option 3 ?? Isn't it just an incredible
> slow DES ?? (As 3DES is EDE)
The clever thing about option three is it give the following possibility.
If you have a large network of single DES encryption processors and need to
upgrade to triple DES you can change all your hardware to triple DES (which
is some cases may take over a year) while keeping your whole network working
with single DES. Then when your entire network is triple DES capable you
can switch your entire network over to triple DES overnight by simply
changing the key values.
------------------------------
From: rot26 <[EMAIL PROTECTED]>
Subject: Re: t
Date: Fri, 22 Sep 2000 17:05:25 GMT
In article <8qc24a$nri$[EMAIL PROTECTED]>,
"lala" <[EMAIL PROTECTED]> wrote:
> t
>
>
http://x72.deja.com/getdoc.xp?AN=672322425
looks like the alt.security.pgp folks are less imaginative (or less
decompression oriented). Note the strange reply by lala though...
reminds me of the (UK only?) Fosters advert "he who drinks Australian,
thinks Australian."
rot26
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
