Cryptography-Digest Digest #859, Volume #12 Fri, 6 Oct 00 21:13:00 EDT
Contents:
Re: one time pad using a pseudo-random number generator ("Paul Pires")
Re: It's Rijndael ("Trevor L. Jackson, III")
Re: It's Rijndael (Marc)
Re: one time pad using a pseudo-random number generator ("Trevor L. Jackson, III")
Re: Why trust root CAs ? (Bruce Stephens)
Re: one time pad using a pseudo-random number generator ("William A. McKee")
Re: It's Rijndael (Jim Gillogly)
Re: Adobe Acrobat -- How Secure? (Benjamin Goldberg)
Re: RC6 royalty free or not? (Tom St Denis)
Re: It's Rijndael (Paul Rubin)
Re: Looking Closely at Rijndael, the new AES (dbt)
Re: CRC vs. HASH functions (Mack)
Re: Storing an Integer on a stream (Benjamin Goldberg)
Re: ISAAC PRNG ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: one time pad using a pseudo-random number generator
Date: Fri, 6 Oct 2000 15:14:42 -0700
William A. McKee <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Is using a strong pseudo-random number generator (2^19937) as a one-time pad
> a good way to encrypt data? If not, why?
I think this is all just a matter of terminology.
If I got it wrong, watch the pounces.
A PRNG is not an OTP by definition since it is deterministic
rather than being harvested from a good random crop. It has more
to do with how the pad was derived that the nature of the pad.
All PRNG's are not "Cryptographically secure" i.e. unpredictable,
(can't predict the next output from knowing the generator
and the past output) and irreversible (can't run it backwards and
find the seed)
A PRNG used in lieu of the pad is much more like RC4
than OTP.
In answer to your question (is this a good way?) It depends on
if it is a good stream cipher, what you consider good and what
you are going to use it for. The best solution might be a block
cipher.
Paul
------------------------------
Date: Fri, 06 Oct 2000 18:47:41 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Runu Knips wrote:
> Doug Kuhlman wrote:
> > Mok-Kong Shen wrote:
> > > I have the impression that increasing rounds is no problem
> > > for Rijndael. If this is done by its own team, it appears
> > > to be not too risky in 'extrapolating' to say that the
> > > result would also be o.k. just as at the present. Those
> > > who are very conservative could apply a safety factor
> > > to take into account of any presumed eventuality, I suppose.
> > At the complete sacrifice of interoperability (as it's currently set
> > up). And a loss in speed. For a questionable increase in security.
>
> Agreed. The main benefit of the standard is the interoperability,
> and this is lost if you modify the algorithm.
Disagree. 3DES offers all the interoperability the USG could want,
including a much smoother transition process.
The fundamental purpose of the contest was to replace DES with a cipher
that is "secure enough" for unclassified USG use. One can appreciate the
main benefit by inspecting the situation without such a standard.
Interoperability would not suffer appreciably, even having every
department select their own ciphers. But security would. Some
departments might choose a cipher that was inadequate others might choose
a cipher that was overly expensive (performance is not free). These are
the problems that the existence of a purchasing standard solves.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: It's Rijndael
Date: 6 Oct 2000 22:53:54 GMT
>> I don't see where there has been broad interoperability in the past,
>> and where it will be in the future. Every application that uses
>> crypto has its own specs. Sure, often the specs refer to DES when
>
>SSL, IPsec, OpenPGP, to name three. I imagine there will be widely
>available interoperating encrypted chat apps before long, if there
>aren't already.
This is not the point. SSL is a "product" of its own. If SSL had been
spec'ed to add 0x1234 to each cleartextblock before encrypting, just
as many SSL clients/servers would interoperate as do today.
What I'm trying to say is that when someone uses AES his product
does not "automagically" interoperate with other products whose
designers also happened to choose AES.
------------------------------
Date: Fri, 06 Oct 2000 19:00:52 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: one time pad using a pseudo-random number generator
"William A. McKee" wrote:
> Is using a strong pseudo-random number generator (2^19937) as a one-time pad
> a good way to encrypt data? If not, why?
>
> TIA,
> Will McKee.
If you are thinking of using the expanded Mersenne Twister the MT description
indicates that it is not of cryptographic quality because a (relatively) small
amount of output allows you to predict the remainder of the stream.
------------------------------
From: Bruce Stephens <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: 06 Oct 2000 23:55:19 +0100
[EMAIL PROTECTED] writes:
> In article <[EMAIL PROTECTED]>,
> Bruce Stephens <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] (Allen Ethridge) writes:
> >
> > [...]
> >
> > > Bruce Schneier's new book, "Secrets and Lies", has an interesting
> section
> > > on certificates and such where, if I understand him correctly, he
> concludes
> > > that the real security in B2C web transactions comes from the credit
> card
> > > company and it's limits on personal liability and not the CA.
> > >
> > > If had the book I'd give the page,
> >
> > pp.238-239.
> >
> > "Digital certificates provide no actual security for electronic
> > commerce; it's a complete sham."
>
> I haven't read the book, so I don't know the context, but CAs are not in
> the business of verifying the legitimacy of a business or transactions
> thereof. CAs merely "sign" the public key of an entity based on the
> entity meeting certain requirements comensurate with the CA signature
> level. [...]
As Allen said, Scheier is (I think) arguing that the reason that
buying at Amazon.com (or wherever) is a reasonable thing to do has
nothing to do with certificates: it's old fashioned stuff like
Amazon's reputation and credit card rules.
A web browser allows the user to view the certificate used when
connecting over TLS, but just about nobody looks at it, and few people
are in a position to evaluate the information even if they did. So
the TLS is basically providing confidentiality (which isn't a bad
thing, of course)---it's not really assuring that the confidential
connection is to someone that ought to be trusted.
Also, not all online shops host their own payment stuff. So although
I'm trying to buy stuff from www.random-shop.com, when I come to buy
it, I may well be redirected to https://secure.honest-joes.com/ to pay
for it.
How am I to evaluate the validity of that kind of thing---certificates
don't help, since (as you say) CAs aren't in the business of verifying
that kind of relationship? At best I can determine that I'm really
talking to secure.honest-joes.com, but that doesn't tell me whether
that makes it safe to enter my credit card information.
When it comes down to it, I don't think the quote is that far off:
these certificates aren't buying me that much. Mostly I'm relying on
credit card rules, and reputation.
(I recommend the book. It's not without minor irritations (of style;
I'm in no position to judge the content), but overall it definitely
works. I've seen descriptions which suggest it's non-technical, but
don't be put off by that: nothing seems forced, as sometimes happens
when authors try to dumb down books.)
------------------------------
Reply-To: "William A. McKee" <[EMAIL PROTECTED]>
From: "William A. McKee" <[EMAIL PROTECTED]>
Subject: Re: one time pad using a pseudo-random number generator
Date: Fri, 06 Oct 2000 23:24:38 GMT
Is there a replacement for MT that is of cryptographic quality?
Will.
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "William A. McKee" wrote:
>
> > Is using a strong pseudo-random number generator (2^19937) as a one-time
pad
> > a good way to encrypt data? If not, why?
> >
> > TIA,
> > Will McKee.
>
> If you are thinking of using the expanded Mersenne Twister the MT
description
> indicates that it is not of cryptographic quality because a (relatively)
small
> amount of output allows you to predict the remainder of the stream.
>
>
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Sat, 07 Oct 2000 00:01:36 +0000
Marc wrote:
> This is not the point. SSL is a "product" of its own. If SSL had been
> spec'ed to add 0x1234 to each cleartextblock before encrypting, just
> as many SSL clients/servers would interoperate as do today.
>
> What I'm trying to say is that when someone uses AES his product
> does not "automagically" interoperate with other products whose
> designers also happened to choose AES.
Interesting use of "product", but OK. If you're building your own
Secure-IRC client and want it to interoperate with somebody else's
Secure-IRC server, it would be helpful if you could simply grab the
AES code from FreeSWAN IPsec, or use standard OpenSSL AES calls that
you see in some OpenPGP implementation without worrying about where to
dink the code to get a different number of rounds. You'll probably
say that if you don't understand every line of the code you have no
business implementing crypto in a real product, and I'll admit there's
some justice in that; but allowing reuseable code with fewer
modifications leads to fewer debugging problems, and allows easier
testing with standard validation suites.
Also, allowing an arbitrarily flexible number of rounds while still
calling it AES will be confusing to the customers. Someone may
advertise "Our AES has a throughput of 350 Mb/s on a PPro 200."
The pointy-haired manager will think this sounds great, even if the
crypto engineer tells him that factor of five speed-up was gained
by cutting the rounds from 10 to 2. You may sneer at this, but I
swear there are people who say 40-bit DES is good enough for a
product because DES is a standard.
I suppose I've missed your point again. Oh, well.
--
Jim Gillogly
Sterday, 15 Winterfilth S.R. 2000, 23:50
12.19.7.10.19, 2 Cauac 2 Yax, Third Lord of Night
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Adobe Acrobat -- How Secure?
Date: Sat, 07 Oct 2000 00:01:44 GMT
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > Tom St Denis wrote:
> > > "David C. Barber" <[EMAIL PROTECTED]> wrote:
> > > > I am looking to distribute some documents I don't want the user
> > > > to be able to alter or print.
> > > When are people going to realize that crypto is NOT FOR PREVENTING
> > > ALTERATIONS ON PLAINTEXT!. If you decrypt something I send you
> > > (say via PGP) there is NO WAY I can stop you from editting it.
> >
> > However, cryptography certainly *can* be used to prevent the
> > undetected alteration of a copy of the *distributed* file,
> > i.e. the one that has been cryptographically signed by the
> > author and is therefore verifiable as authentic.
>
> I was specifically hinting at the "altering" or "printing" part. I
> can alter a document you send me, I can copy/print/resend a document
> you send me. I can't fake a signature, but that wasn't my point.
Are there any printers which check the signatures of files sent to it?
This idea is sort of like a printer version of SMDI.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC6 royalty free or not?
Date: Sat, 07 Oct 2000 00:18:53 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Runu Knips <[EMAIL PROTECTED]> wrote:
> > > "Sami J. M�kinen" wrote:
> > > > I couldn't tell by reading the papers from RSA webpage that
> > > > is RC6 royalty free or not (to use in shareware program)?
> > > > I'm talking about the algorithm itself, not any implementation.
> > >
> > > Use any of the other AES finalists. RSADSI has AFAIK only
> > > stated that RC6 will be free _IF_ it would become AES,
> > > and it hasn't.
> > >
> > > If at all, I would use RC6 with at least 12, better 16
> > > rounds, btw.
> >
> > Um RC6 was specified with at least 20 rounds, 17 of which can be
broken
> > with 2^118 work...
>
> Ooops true I don't know where I get the impression it was
> less... ?
>
> Quite a lot of rounds, indeed.
>
Well really RC6 is secure with 20 rounds, and RC5-32 is secure with
16....
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: 06 Oct 2000 17:33:31 -0700
Jim Gillogly <[EMAIL PROTECTED]> writes:
> Also, allowing an arbitrarily flexible number of rounds while still
> calling it AES will be confusing to the customers. Someone may
> advertise "Our AES has a throughput of 350 Mb/s on a PPro 200."
> The pointy-haired manager will think this sounds great, even if the
> crypto engineer tells him that factor of five speed-up was gained
> by cutting the rounds from 10 to 2. You may sneer at this, but I
> swear there are people who say 40-bit DES is good enough for a
> product because DES is a standard.
You can be equally sure that some users will insist on using triple AES,
since they were using triple DES before and want to be extra sure.
There will also be all the same debates we've already had here about
3DES, asking whether it's better to use 3AES in EEE or EDE mode, and
whether to use two keys or three independent keys (two keys makes it
easier to, um, interoperate with legacy single-AES implementations,
yeah that must be it). What a field.
------------------------------
From: [EMAIL PROTECTED] (dbt)
Subject: Re: Looking Closely at Rijndael, the new AES
Date: Sat, 07 Oct 2000 00:33:43 GMT
Thomas Pornin <[EMAIL PROTECTED]> says:
>According to Paulo S. L. M. Barreto <[EMAIL PROTECTED]>:
>> Yet if you don't accept that as secure, then just forget *anything*
>> else.
>
>Not quite. OTP is ultimately secure against passive attacks
>(eavesdropping) but not at all against active attacks (the bad guy
>intercepts and modifies the message). It is easy, from a known
>plaintext, to calculate the ciphertext corresponding to any other
>plaintext of same length.
And this is a very real problem in OTP-like ciphers like RC4. The
SSH insertion attack is a good example.
--
David Terrell | "Instead of plodding through the equivalent of
Prime Minister, NebCorp | literary Xanax, the pregeeks go for sci-fi and
[EMAIL PROTECTED] | fantasy: LSD in book form." - Benjy Feen,
http://wwn.nebcorp.com | http://www.monkeybagel.com/ "Origins of Sysadmins"
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: CRC vs. HASH functions
Date: 07 Oct 2000 00:57:08 GMT
>Mack wrote:
>> >Mack wrote:
>> >
>> >> 1) CRC are faster than HASH functions of
>> >> comparable size. That is a fact. Many
>> >> hash functions use a CRC like layer at the
>> >> top to mix in data linearly. SHA-1 is no exception.
>> >> A table driven 256 bit hash function requires 4 32-bit word
>> >> lookups/byte, four 32-bit word XORs, a shift and an XOR
>> >> to add data.
>> >
>> >A table driven hash function? Did you mean a CRC? In any
>> >case, I'd like to see the algorithm to compute a 256 bit
>> >result with the stated operations.
>
>> Ack yes ... of course a table driven hash function is a possibility.
>> Hmmm ... yes ... full of possibilities.
>>
>> Of course I did mean table driven CRC function. Sorry for the error
>> it has been a long long month.
>
>I'd still like to see the algorithm. It's not obvious to me
>how to get a 256 bit CRC from four of each of the 32-bit
>operations/byte. You wrote that a 16-bit table (16-bit input
>I assume) would require even fewer lookups, so I assume you
>index in 8-bit units. I think I see how to update a 128-bit
>CRC with roughly those ops, but even then my shifting comes
>out significantly worse when working with 32-bit words.
>
Actually all those figures were supposed to be for a 128 bit CRC in the general
case. That was another error on my part.
Sorry the shift operation is on a 128 bit word. Should have
specified that. It breaks down to 8 32-bit shifts and 4 other 32-bit
operations.
The four others can be XOR or OR. Since all of the affected bits are
zero. It doesn't matter which.
The XOR to add info actually only needs to be done once ever four operations.
I have a specific 256 bit CRC that I like that reduces the total number of
operations. 2^256+2^193+2^113+2^6+1. In that case the bit-wise operation
only uses 4 bit to updata. In fact in bitwise operation it is possible to do
away
with the shifts entirely.
There is a method for a 256 bit poly that uses 4 lookup tables and no shifts at
all. You have 8 word lookups/byte and 1 AND and 8 XORs. It rotates the data
in place to emulate shifts. Data is added every four bytes. That is the most
efficient version I have. The above poly reduces that figure of lookups and
XORs
to 3 each.
Anyone have a hash function that can beat it for speed?
>
>--Bryan
>--
>email: bolson at certicom dot com
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
>
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Storing an Integer on a stream
Date: Sat, 07 Oct 2000 00:58:15 GMT
SCOTT19U.ZIP_GUY wrote:
>
> [EMAIL PROTECTED] (Benjamin Goldberg) wrote in
> <[EMAIL PROTECTED]>:
>
> >If I'm writing a file, whose format is a 64 bit file length, followed
> >by some amount of data, followed by some [random] padding, which of
> >the following is the best way to store that length value:
>
> If you want it to be secure from a information point of view so
> that no information is added to the file.
This sentence no verb.
> You can use my DSC program.
If I could find it. You didn't give a URL.
> If the file data is in whole bytes. and the padding starts on a word
> boudary.
That sentence no verb.
> You can use my code without any modification at all. However the
> format of your file would have to change. Instead of a length field
> followed by data followed by random padding.
This sentence also no verb.
> You would have the data followed by random padding followed by a
> pointer that points to the start of the random padding.
In terms of amount of information, there is no difference between length
+ data + padding and data + padding + length. Also, either way, I asked
how write a length value as some number of bytes. My post was asking
what is the best way to do that.
> You have all the information of the first file in a form that is
> better suited for encryption.
What proof do you have that your method is better suited than mine? I'm
not saying it isn't, but I want to know what basis you use to make this
assertion. If I were stating something were better, I would usually add
"IMHO" or (in your case) "IMNSHO." Stating an opinion as a fact, and
not offering evidence to back it up makes you look like an ass.
I will admit, however, that if one is encoding the integer using a
variable number of bytes, storing the padding length can be better than
storing the file length because the padding is generally much shorter
than the file. On the other hand, since the purpose of the padding is
to make the file length precisely a multiple of the cipher block size,
it may be difficult to do, since length of the encoded length can't be
found until the length of the padding is known, and the length of the
padding is chosen so that ( data + padding + padding length ) % block
size = 0.
Thus, your method of writing the padding length at the end of the file,
instead of writing the data length at the front, doesn't work at all if
the length of the padding is variable, and only works if the number is
written as a fixed number of bytes (or bits).
To optimally use your method when the block size is 128 bits (16 bytes),
we can have the last byte of padding consist of 4 random bits plus a 4
bit integer, saying how much of the data before that byte is padding.
In fact, using [part of] just the final byte to describe the length of
the padding will work with any block size up to 256 bytes.
Unfortunately, this method gives some number of bits of known plaintext.
If we use the method I described in the post that started this, we can
add as many blocks of padding as I desire. There are tradeoffs with
both methods, either giving some bits of known plaintext, or some bytes
of probable plaintext.
> If you don't like this rearangement of format you can edit DSC to make
> it fit what you want. The source code is included.
IF your method does something other than one of those things I described
above, I would appreciate a URL.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ISAAC PRNG
Date: Sat, 07 Oct 2000 00:49:33 GMT
In article <8rj66u$3mr$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi all,
>
> Is anyone aware of any effort to cryptoanalyse the Robert Jenkin's
PRNG
> ISAAC?
>
> The web site for this algorithm is at:
>
> http://burtleburtle.net/bob/rand/isaacafa.html
>
> Regards,
>
> Unseenrising
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
No.
- Bob Jenkins
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
******************************
