Cryptography-Digest Digest #856, Volume #12 Fri, 6 Oct 00 11:13:01 EDT
Contents:
Re: Microsoft CAPI's PRNG seeding mechanism ("Joseph Ashwood")
Re: Decryption speeds? ("Joseph Ashwood")
Re: TEA (Mok-Kong Shen)
Re: Newbie question to practical brute-force analysis ("Joseph Ashwood")
Re: The best way to pronounce AES (John Savard)
Re: OpenSSL and Twofish (Runu Knips)
Re: TEA (Runu Knips)
Re: It's Rijndael (Thomas Pornin)
Re: TEA (Runu Knips)
Re: Looking Closely at Rijndael, the new AES (Thomas Pornin)
Re: The best way to pronounce AES (Volker Hetzer)
Re: RC6 royalty free or not? (Runu Knips)
Re: BlowFry... ("Rob Marston")
ISO an SHA-1 Implemention in Javascript ("Arnold Shore")
Re: Any products using Rijndael? (Runu Knips)
Oblivious transfer.... ("Gabby")
Storing an Integer on a stream (Benjamin Goldberg)
Storing an Integer on a stream (Benjamin Goldberg)
RE: The best way to pronounce AES ("Manuel Pancorbo")
Re: Storing an Integer on a stream (SCOTT19U.ZIP_GUY)
Re: are doubly encrypted files more secure than singly encrypted ones? (John Savard)
Re: No Comment from Bruce Schneier? (John Savard)
Re: Microsoft CAPI's PRNG seeding mechanism (JCA)
Re: Signature size ([EMAIL PROTECTED])
Re: CRC vs. HASH functions (Zulfikar Ramzan)
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Microsoft CAPI's PRNG seeding mechanism
Date: Thu, 5 Oct 2000 11:35:10 -0700
Crossposted-To: sci.crypt.random-numbers
> do I have to trust
> Microsoft about their crypto
> capabilities ?
Honestly, with Microsoft's extended history of security failures in every
way, I would suggest that you avoid depending on their code, regardless of
the amount of documentation they supply.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Decryption speeds?
Date: Thu, 5 Oct 2000 11:47:46 -0700
"John Myre" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Robert Hulme wrote:
> >
> > I have to write up a report specifying the amount of time it would take
a
> > hacker brute force attack certain algorithms.
> <snip>
> > Does anyone know of a page that lists this kind of information?
Don't know of any page off-hand but since you limited yourself to brute
force, I can give you the answers:
56-bit : 22 hours (baseline assumption from DES Challenge)
1,2,4,8,16,32-bit: effectively instantaneous
40-bit : less than an hour
64-bit: 234 days
80 -bit : 42000 years
128-bit : 10**18 years
194-bit : 10**36 years
256-bit : 10**54 years
These are of course subject to small multiplication by fairly small
constants, and halving every couple years. Also remember that the DES
challenge occured a while ago, and was broken by a non-profit organisation,
if your hacker is the head of IT at <insert name of large bank here> their
resources will be far greater, and they can make vast leaps towards breaking
80-bits.
Of course this is all because you limited yourself to brute force, and as
you can see it is certainly not the way to attack anything above 64-bits.
>From there you need to examine the best known method of attack, and that
varies greatly based on algorithm.
Joe
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: TEA
Date: Fri, 06 Oct 2000 12:41:46 +0200
Runu Knips wrote:
>
> David Wagner wrote:
> > Use a trusted cipher; 3DES, if you can afford it, or AES, if not.
>
> I don't understand why you trust 3DES and Rijndael more than
> Blowfish or Serpent, especially because NIST said explicitly
> that Serpent offers more security than AES/Rijndael, and the
> OP asked for a _SIMPLE_ cipher.
As someone recently said, crypto has something to do with
superstition. It is anyway a fact that trust can never be
entirely objective and thus is not to be founded in a way
like a mathematical theorem. Since DES has stood well
against decades of analysis, excepting being broken by
brute force, and 3DES has been widely used, this asset
of experience cannot be ignored, I suppose. On design
'simplicity', I think that Rijndael is superior to
Serpent and Blowfish.
M. K. Shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Newbie question to practical brute-force analysis
Date: Thu, 5 Oct 2000 11:53:25 -0700
> Is it true that more than a gigabyte of ciphertext
> is likely to be required to detect the bias in RC4?
The current understanding is that there is no detectable bias beyond 1/2^24,
this may or may not be the actual case.
> Does RC4's bias become a problem only in ciphertext
> generated using a single key?
Yes. As with all ciphers if you change the key in an independent way an
attacker will be forced to start over.
> In other words, is the "RC4 bias problem" solved by
> never using a single key for more than, say, a few
> megabytes of text?
As long as you always throw out the first bytes (there is a known bias in
the first byte) also, yes that will prevent the currently known methods of
detecting bias.
Joe
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The best way to pronounce AES
Date: Fri, 06 Oct 2000 10:31:55 GMT
On 6 Oct 2000 09:25:45 GMT, [EMAIL PROTECTED] (Scott
Craver) wrote, in part:
> That would be funny. Of course, RIJNDAEL, so YMMV.
>From context in your example, someone might come up with:
TWOF:
The way (it's) often fixed
The way of fixing
Although the other one is a little harder:
RIJNDAEL:
Really, I just now defined acronyms (in the) English language.
Really, I just now disclosed all (the) evil logic.
Really, I just now devised an equivalent logogram.
And this one, of course, is real:
YMMV: Your mileage may vary.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Fri, 06 Oct 2000 12:50:42 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: OpenSSL and Twofish
R�mi Guyomarch wrote:
> Runu Knips wrote:
> > Btw, it would be nice if someone could give me a pointer to good
> > documentation about OpenSSL, how to use it and what all theses
> > functions actually mean.
>
> The best I found is the old SSleay documentation :
> http://www.columbia.edu/~ariel/ssleay/
Thank you ! I'll check that now.
> Documentation on openssl.org is either incomplete or inaccurate,
> sometimes both :-(
Yep :-(
------------------------------
Date: Fri, 06 Oct 2000 12:57:38 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: TEA
Sam Simpson wrote:
> Runu Knips <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > In fact I just noted GHOST because the OP is a russian.
>
> It's GOST!
Argl, yep.
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: It's Rijndael
Date: 6 Oct 2000 11:21:16 GMT
It is hard to find an example where all problems will be critical, but:
> Are you really so concerned about the hardware cost that
> is constantly falling?
Three weeks ago, I decided I needed:
-- a bigger television, with a DVD
-- a new computer
But I could not afford both. I chose the television.
Therefore my Cyrix PC, incapable of launching Diablo II, tells me that
hardware cost is a problem.
On a more "serious" line, the difference between a 0.5$ smartcard and
a 0.6$ smartcard can become tremendous, if you build 100 millions of
those.
> Power cost may go up eventually due to OPEC, but what's your bill?
Two problems with power consumption:
-- mobile computing (think mobile phones, or radio-powered smartcards)
-- heat (you stick your mobile phone yo your ear; do you want it to be
really hot ?)
> Through pipelining there should be negligible effect on the throughput
> of multiple encryption
... if you accept to triple the hardware (and therefore power
consumption and hardware cost). Otherwise, your data must make three
rides through the same gates, so bandwidth is divided by three. You
cannot have it both ways, since you have thrice the work to do.
> What kind of critical realtime applications do you have in which a
> latency really hurts?
Network data routing. You get the beginning of a packet, and you must
decide *quickly* where to route the packet. If the routing data is
encrypted, you must decrypt it first.
To illustrate the "quickly": some modern, high-bandwidth routers work in
full-optic mode: the packet enters from an optic fiber, the header is
processed in an optic circuit, while the data is stored on a piece of
fiber: the finite lightspeed ensures that the storage is possible. They
do it that way because storing the data in a circuit (either electric or
optic, with bistable gates) would induce too much latency.
> (Are you sure that the transmission protocol wouldn't sometimes give
> you inadmissible latency?) Just a few thoughts of mine.
Whatever are your engineering requirements, there will always be some
application that needs more. It is a bit paradoxal, but security, at
least, can be made optimal: there is a point where nobody can break the
system, period. But the hardware will always have a cost, and reducing
it will make winners and losers in the marketplace.
--Thomas Pornin
------------------------------
Date: Fri, 06 Oct 2000 13:22:12 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: TEA
Mok-Kong Shen wrote:
> On design 'simplicity', I think that Rijndael is superior
> to Serpent and Blowfish.
Hmm. Maybe if one knows what GF maths is...
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: Looking Closely at Rijndael, the new AES
Date: 6 Oct 2000 11:25:54 GMT
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.
--Thomas Pornin
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: The best way to pronounce AES
Date: Fri, 06 Oct 2000 13:39:50 +0200
John Savard wrote:
> TWOF:
> The way (it's) often fixed
> The way of fixing
ILTO! (I like that one) :-)
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
Date: Fri, 06 Oct 2000 13:45:56 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: RC6 royalty free or not?
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.
------------------------------
From: "Rob Marston" <[EMAIL PROTECTED]>
Subject: Re: BlowFry...
Date: Fri, 6 Oct 2000 12:49:09 +0100
I apologise for posting the previous binary attachment. I didn't read the
newsgroup
policy correctly...
Sorry..
Rob
------------------------------
From: "Arnold Shore" <[EMAIL PROTECTED]>
Subject: ISO an SHA-1 Implemention in Javascript
Date: Fri, 6 Oct 2000 08:14:33 -0400
Will appreciate any information on subject matter availability. I'm aware
of a couple of MD5 implementations around, but haven't found an SHA source.
Thanks, folks.
Arnold Shore
Annapolis, MD USA
------------------------------
Date: Fri, 06 Oct 2000 14:10:21 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Any products using Rijndael?
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> Runu Knips <[EMAIL PROTECTED]> wrote:
> > [...] AES/Rijndael and IDEA are also ciphers with
> > not too low security. [...]
>
> How do you figure IDEA is not secure?
Hu ? I didn't want to say 'IDEA is not secure', I said 'is
also a cipher with not too low security', which means 'is
quite secure', doesn't it ?
------------------------------
From: "Gabby" <[EMAIL PROTECTED]>
Subject: Oblivious transfer....
Date: Fri, 6 Oct 2000 15:07:27 +0200
I want to find this paper:
Mihir Bellare, Silvio Micali:
Non-Interactive Oblivious Transfer and Spplications.
Where do I find it ?
If you have this please send my to [EMAIL PROTECTED] or [EMAIL PROTECTED]
Thanks !!!!
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Storing an Integer on a stream
Date: Fri, 06 Oct 2000 13:34:28 GMT
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:
1) 8 base-256 digits. With this format, we always use 8 bytes.
2) Some number of base-255 digits, with leading 0 digits stripped,
terminated by the value 255. With this format, we always use at least 1
byte (for a value of 0, which is written as just the terminator (255)),
but generally use 2..9 bytes.
3) Some number of base-128 digits, with leading 0 digits stripped, all
but the last prefixed by a 0 bit, and the last prefixed by a 1 bit.
With this format, values 0..127 use 1 byte, 128..(128**2-1) uses 2
bytes, etc, with 9 bytes being used for a 63 bit value, and 10 bytes
used for a 64 bit value.
Since this file will be encrypted, any file lengths that are
significantly less than 2**64, which is most files, will give some known
plaintext of leading 0s with method 1. I made a suggestion of using
method 3, to avoid this problem, but someone (I forget who) said that
method 2 was more space efficient. Does anyone have any comments? Both
on space-efficiency and on difficulty of using it for trial decryptions.
By the way, I think I should mention that in the perl programming
language, the builtin functions pack() and unpack() have a template type
for method 2, which (If I recall correctly) uses the letter 'w' and is
refered to as Berweiss-encoding of an integer.
--
... 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: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Storing an Integer on a stream
Date: Fri, 06 Oct 2000 13:40:09 GMT
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:
1) 8 base-256 digits. With this format, we always use 8 bytes.
2) Some number of base-255 digits, with leading 0 digits stripped,
terminated by the value 255. With this format, we always use at least 1
byte (for a value of 0, which is written as just the terminator (255)),
but generally use 2..9 bytes.
3) Some number of base-128 digits, with leading 0 digits stripped, all
but the last prefixed by a 0 bit, and the last prefixed by a 1 bit.
With this format, values 0..127 use 1 byte, 128..(128**2-1) uses 2
bytes, etc, with 9 bytes being used for a 63 bit value, and 10 bytes
used for a 64 bit value.
Since this file will be encrypted, any file lengths that are
significantly less than 2**64, which is most files, will give some known
plaintext of leading 0s with method 1. I made a suggestion of using
method 3, to avoid this problem, but someone (I forget who) said that
method 2 was more space efficient. Does anyone have any comments? Both
on space-efficiency and on difficulty of using it for trial decryptions.
By the way, I think I should mention that in the perl programming
language, the builtin functions pack() and unpack() have a template type
for method 2, which (If I recall correctly) uses the letter 'w' and is
refered to as Berweiss-encoding of an integer.
--
... 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: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: RE: The best way to pronounce AES
Date: Fri, 6 Oct 2000 15:58:31 +0200
Tom St Denis <[EMAIL PROTECTED]>
> In article <8rhqqt$r0s$[EMAIL PROTECTED]>,
> "Manuel Pancorbo" <[EMAIL PROTECTED]> wrote:
> >
> > Scott Craver <[EMAIL PROTECTED]>
> >
> > > I know I have no authority to decide these things, but I
> > > strongly feel that "AES" should be pronounced, "uh-YES."
> > >
> >
> > I don't understand why anglos have so many childish problems to
> pronounce so
> > stupidly easy things. Pronounce it simply foneticly [a-es]; that's
> all. ;-)
>
> Ok... pronouce the word "aesthetic".... hehehe
>
Ooops... you (anglos) are impossible...
Ok, get the fonetic alfabet and look for the symbols [a], [e], [s]. Simply
pronounce them in this order [a]-[e]-[s]. Isn't it yet enough easy for you?
;-)
Manuel Pancorbo
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Storing an Integer on a stream
Date: 6 Oct 2000 14:07:08 GMT
[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. You can use my DSC program.
If the file data is in whole bytes. and the padding starts on a word
boudary. 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.
You would have the data followed by random padding followed by a
pointer that points to the start of the random padding. You have all
the information of the first file in a form that is better suited
for encryption. 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.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: are doubly encrypted files more secure than singly encrypted ones?
Date: Fri, 06 Oct 2000 13:38:56 GMT
On Fri, 06 Oct 2000 08:55:05 GMT, jtnews <[EMAIL PROTECTED]>
wrote, in part:
>If I use gnupg on a file and then encrypt the encrypted file again
>is it anymore secure? Will it take longer for someone to crack it?
Not with a program like GNU Privacy Guard, perhaps. Even if you use
conventional encryption, with a different key for each step, there is
still the problem that it will treat an encrypted file as a general
text file, instead of extracting the encrypted bits from it to only
encrypt them.
So you are almost certain to wind up with it only taking N times as
long to crack it, if you encipher N times. This would not, however, be
true if you did repeated conventional encryption _without armoring_
except for the final encryption. Then you would finally get the
benefit of multiple encryption.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: No Comment from Bruce Schneier?
Date: Fri, 06 Oct 2000 13:34:58 GMT
On Fri, 06 Oct 2000 21:06:37 +1100, David Blackman
<[EMAIL PROTECTED]> wrote, in part:
>There are rumours he may have made a comment to the US media. I expect
>he will make a comment in his monthly newsletter on the 15th also. Be
>patient. It's only a few days away.
The posting that began:
>An article on The Standard, available at
>http://www.thestandard.com/article/display/0,1151,19101,00.html says
shows that it is more than just a rumour; he did congratulate the
Rijndael team and accept defeat with good sportsmanship.
Oh: in looking through some of my books, I learned something about
Galois fields which caused me to add a brief comment to my description
of Twofish.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: JCA <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Microsoft CAPI's PRNG seeding mechanism
Date: Fri, 06 Oct 2000 07:30:18 -0700
Pascal JUNOD wrote:
> Does someone have any information about it, or do I have to trust
> Microsoft about their crypto
> capabilities ?
>
If anything, you would have to adopt the opposite attitude: trust that
their crypto capabilities are flawed.
MS is well-known for not taking security seriously.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Signature size
Date: Fri, 06 Oct 2000 14:39:56 GMT
Hi -
The NTRU signature size is the same as the public
key size. The algorithm is posted at:
http://www.ntru.com/technology/tech.technical.htm
(I think it's the first paper listed - the
NSS "NTRU Signature Scheme" paper...).
Yours,
Daniel
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 06 Oct 2000 10:55:18 -0400
From: Zulfikar Ramzan <[EMAIL PROTECTED]>
Subject: Re: CRC vs. HASH functions
There is a body of literature that discusses relationships between coding theory
and message authentication.
For example, many MACs are constructed using 2-universal hash functions composed
with some type of cryptographic hash. The idea is to use the hash function to
operate on the full message, and produce a small tag, and then apply the
cryptographic construct to this smaller tag. This approach (hopefully) saves time
since the cryptographic work is done on a small tag.
UMAC is one such approach. A number of other universal hash function
constructions have been proposed, and many of them are based on constructions from
coding theory.
Whether a CRC is "better" than a hash function is not well defined until you
specify what you mean by "better." If you're interested in message authentication
or integrity, for example, a CRC by itself is not enough.
Zulfikar
Scott Fluhrer wrote:
>
> Mack <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Having been working hard and not here for a while
> > the topic of CRC vs. HASH functions
> > came up in a thread.
> >
> > 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 16-bit lookup uses fewer lookups but much bigger
> > tables.
>
> However, if you are willing to use a MAC rather than a HASH (which may be
> appropriate depending on why you are summarizing the file in the first
> place), there are MACs which can be even faster than CRC. Examples of this
> would include UMAC (http://www.cs.ucdavis.edu/~rogaway/umac/) and hash127
> (http://cr.yp.to/hash127.html)
>
> --
> poncho
--
--Zully
=======
Zulfikar Ramzan (AKA Zully)
Laboratory for Computer Science, MIT
NE43-311, (617) 253-2345
http://theory.lcs.mit.edu/~zulfikar/homepage.html
------------------------------
** 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
******************************
