Cryptography-Digest Digest #504, Volume #14 Sun, 3 Jun 01 14:13:01 EDT
Contents:
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Def'n of bijection ("Tom St Denis")
Re: Luby-Rackoff Theorems? (Nicol So)
Re: Def'n of bijection (Nicol So)
Re: BBS implementation ([EMAIL PROTECTED])
Re: Def'n of bijection ("Tom St Denis")
Re: BBS implementation ("Tom St Denis")
Re: Large Number Math Package ([EMAIL PROTECTED])
Re: Large Number Math Package ("Tom St Denis")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Sun, 3 Jun 2001 16:34:38 GMT
Roger Fleming <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] wrote:
:>What are the problems from "the conventional viewpoint" that are pointed
:>out with the use of big keys?
: 1. Ensuring good key diffusion becomes difficult. If good key diffusion does
: not occur, the cipher may become vulnerable to 'meet in the middle' style
: attacks or 'correlation attacks' that attck parts of the key piecemeal, making
: the cipher strength partially linear in the key instead of exponential. This
: is BAD.
Ensuring good key diffusion may become more computationally
demanding, but it can be done using a simple hash function - I
wouldn't say there was anything especially dificult about it.
There may be a computational cost - but it's only going to affect key
agility, not encryption/decryption throughput.
: 2. The sort of ciphers he was talking about often have HUGE keys, eg we all
: know of one that has keys of over 1 MB.
Yes - I didn't mean to refer to OTP-style scenarios.
:>Are you talking about key distribution problems? [...]
: 3. Transmission and storage of such keys is a serious problem. The
: whole point of ciphers is that a large secret (the message) can be
: protected by a small secret (the key).
Hmm. Some would say that the whole point of cyphers is protecting the
message, and it doesn't matter how you do it.
If you exchanges a huge key when you met in person last week, I don't see
any good reason not to take advantage of it.
: When the 'small' secret is 1 MB, how do you protect _it_?
Put it on a CD ROM, and lock it in your safe?
: The answer usually offered seems to be, put it on a floppy and lock it
: in your safe (if you have one) - in which case, why not leave your
: files in the safe...
Locking your files in a safe doesn't help with communicating the latest
news to Bob. Locking an shared key in your safe might well do.
: You end up with a cipher which offers only-as-good-as-your-locks
: security [...]
True of any secret key system.
: [...] is nearly useless for network applications [...]
These are tricky at the best of times, due to authentication problems.
: and isn't even portable enough to lug around on your laptop.
Oh, come on! ;-) No key is *that* big.
:>that keys much bigher the 128 bits are useless overkill?
:>Key distribution is indeed a problem - but I don't think anyone could
:>convinvingly argue that 128 bits is enough and more is pointless.
: OK, I will attempt to convincingly argue that 128 bits is (nearly always)
: enough and more is (usually) pointless - for a few decades, anyway. [...]
Hmm. This is what I was afraid of. Trusting that one's cypher's won't be
broken is not something that everyone is prepared to do.
:>AFAICS, allowing variable size keys is not terribly painful in terms
:>of fattening up the key schedule. It seems like a good idea to me.
: It can be a good idea if it is done carefully, but most algorithms that
: get it right seem to use very slow, complex key schedules that limit
: their utility for some purposes.
Hmm. If fed a short key, I see no good reason for such a key schedule to
be any slower than normal.
Large keys have their cost in terms of key schedule, I'd agree - but then
again, the results are more likely to be secure.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Sun, 3 Jun 2001 16:43:03 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
:> > "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
:> >> 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. [...]
No - it is completely correct.
:> 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).
Not at all in fact. Do you realise how wrong that is?
: CTR mode is just a bloody xor of some random bits against a
: message. How can that possibly be less secure than BICOM?
To repeat David Scott's example, consider a 1 byte cyphertext message.
In CTR mode it maps to one of 256 possible plaintexts.
With BICOM it maps to one of *billions* of possible messages.
You tell me which is more likely to be secure.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Sun, 3 Jun 2001 16:47:59 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
:[D. Scott wrote:]
:> 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.
He explained it - you just didn't understand the explanation.
: Besides BICOM can't be a "bijection" if one input maps to several bytes.
Yes it can. Indeed it is.
: Let's say a 1 byte file maps to 3 bytes.
OK.
: Now to be fully bijective you must map all 3 byte files to 1 byte.
A false statement on your part - bijectivity in no way requires such a map
to exist. Want to try again?
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Sun, 03 Jun 2001 17:32:50 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> :> > "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>
> :> >> 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. [...]
>
> No - it is completely correct.
>
> :> 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).
>
> Not at all in fact. Do you realise how wrong that is?
>
> : CTR mode is just a bloody xor of some random bits against a
> : message. How can that possibly be less secure than BICOM?
>
> To repeat David Scott's example, consider a 1 byte cyphertext message.
>
> In CTR mode it maps to one of 256 possible plaintexts.
>
> With BICOM it maps to one of *billions* of possible messages.
>
> You tell me which is more likely to be secure.
But an OTP is provably secure so your question is moot.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Sun, 03 Jun 2001 17:34:44 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> :[D. Scott wrote:]
>
> :> 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.
>
> He explained it - you just didn't understand the explanation.
What explanation? All he does is flame me.
> : Besides BICOM can't be a "bijection" if one input maps to several bytes.
>
> Yes it can. Indeed it is.
>
> : Let's say a 1 byte file maps to 3 bytes.
>
> OK.
>
> : Now to be fully bijective you must map all 3 byte files to 1 byte.
>
> A false statement on your part - bijectivity in no way requires such a map
> to exist. Want to try again?
Um wrong. A bijection is where the domain and range are the same set. I.e
a permutation of 0..255 is a bijection. Squaring modulo a prime is not a
bijection, etc.. (since not all roots have roots, etc..)
So we don't get confused, what is the real def of bijection? I'm not sure
off hand... but from what I gather it's based on permutations.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Sun, 03 Jun 2001 17:40:12 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Roger Fleming <[EMAIL PROTECTED]> wrote:
> : [EMAIL PROTECTED] wrote:
>
> :>What are the problems from "the conventional viewpoint" that are pointed
> :>out with the use of big keys?
>
> : 1. Ensuring good key diffusion becomes difficult. If good key diffusion
does
> : not occur, the cipher may become vulnerable to 'meet in the middle'
style
> : attacks or 'correlation attacks' that attck parts of the key piecemeal,
making
> : the cipher strength partially linear in the key instead of exponential.
This
> : is BAD.
>
> Ensuring good key diffusion may become more computationally
> demanding, but it can be done using a simple hash function - I
> wouldn't say there was anything especially dificult about it.
>
> There may be a computational cost - but it's only going to affect key
> agility, not encryption/decryption throughput.
Using hashes as part of your cipher design is typically the sign of an
amateur.
> : 2. The sort of ciphers he was talking about often have HUGE keys, eg we
all
> : know of one that has keys of over 1 MB.
>
> Yes - I didn't mean to refer to OTP-style scenarios.
>
> :>Are you talking about key distribution problems? [...]
>
> : 3. Transmission and storage of such keys is a serious problem. The
> : whole point of ciphers is that a large secret (the message) can be
> : protected by a small secret (the key).
>
> Hmm. Some would say that the whole point of cyphers is protecting the
> message, and it doesn't matter how you do it.
>
> If you exchanges a huge key when you met in person last week, I don't see
> any good reason not to take advantage of it.
Again I will introduce you to reality. The whole point of cyphers [sic] is
not just protecting the message. It's filling out Maslows Triangle of
needs, it's being buzzword compliant. Which are often more important.
Sure secure ciphers (in the information theoretic sense) are important, but
it's how they are used and what they are suppose todo that is more
important. On top of that they have to be memory, code and speed wise
efficient otherwise what's the point?
> : When the 'small' secret is 1 MB, how do you protect _it_?
>
> Put it on a CD ROM, and lock it in your safe?
Why a CD?
> : The answer usually offered seems to be, put it on a floppy and lock it
> : in your safe (if you have one) - in which case, why not leave your
> : files in the safe...
>
> Locking your files in a safe doesn't help with communicating the latest
> news to Bob. Locking an shared key in your safe might well do.
>
> : You end up with a cipher which offers only-as-good-as-your-locks
> : security [...]
>
> True of any secret key system.
Agreed, but any other system is vastly more efficient.
> : [...] is nearly useless for network applications [...]
>
> These are tricky at the best of times, due to authentication problems.
>
> : and isn't even portable enough to lug around on your laptop.
>
> Oh, come on! ;-) No key is *that* big.
>
> :>that keys much bigher the 128 bits are useless overkill?
> :>Key distribution is indeed a problem - but I don't think anyone could
> :>convinvingly argue that 128 bits is enough and more is pointless.
>
> : OK, I will attempt to convincingly argue that 128 bits is (nearly
always)
> : enough and more is (usually) pointless - for a few decades, anyway.
[...]
>
> Hmm. This is what I was afraid of. Trusting that one's cypher's won't be
> broken is not something that everyone is prepared to do.
Cough, cough. AES.
> :>AFAICS, allowing variable size keys is not terribly painful in terms
> :>of fattening up the key schedule. It seems like a good idea to me.
>
> : It can be a good idea if it is done carefully, but most algorithms that
> : get it right seem to use very slow, complex key schedules that limit
> : their utility for some purposes.
>
> Hmm. If fed a short key, I see no good reason for such a key schedule to
> be any slower than normal.
>
> Large keys have their cost in terms of key schedule, I'd agree - but then
> again, the results are more likely to be secure.
Not true. Using a bigger key doesn't always make the result more secure.
Look at the diff analysis of DES. It can proceed with 768 bit keys with
about the same efficiency as a 56-bit key. Even if we change DES to use a
128-bit key and the best key schedule possible it would still be broken with
2^61 texts and work.
Care to try again [as you are so fond of putting it...]?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Def'n of bijection
Date: Sun, 03 Jun 2001 17:45:04 GMT
http://www.dictionary.com/cgi-bin/dict.pl?term=bijection
Aha. One-to-one and onto.
That means it's invertible and closed right (i.e from set A to set B, A=B)?
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Luby-Rackoff Theorems?
Date: Sun, 03 Jun 2001 13:47:30 -0400
Reply-To: see.signature
I just realized that allowing 2^{n/4} queries (n = block size) is
incompatible with the notion of pseudorandomness used in the
Luby-Rackoff paper. (Polynomial-size oracle circuits cannot have a
superpolynomial # of oracle gates). I need to think about the
implications some more.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Date: Sun, 03 Jun 2001 13:52:54 -0400
Reply-To: see.signature
Tom St Denis wrote:
>
> http://www.dictionary.com/cgi-bin/dict.pl?term=bijection
>
> Aha. One-to-one and onto.
>
> That means it's invertible and closed right (i.e from set A to set B, A=B)?
Invertible? yes. Domain = range? No.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: BBS implementation
Date: Sun, 03 Jun 2001 10:55:46 -0700
I want to know how to initialze it from a key.
Tom St Denis wrote:
> <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Where can I find some info on practical BBS implementation?
>
> Um, square an integer modulo a composite blum integer repeatedly and output
> the log log n lower bits
>
> What else do you want?
>
> Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Date: Sun, 03 Jun 2001 18:01:51 GMT
"Nicol So" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > http://www.dictionary.com/cgi-bin/dict.pl?term=bijection
> >
> > Aha. One-to-one and onto.
> >
> > That means it's invertible and closed right (i.e from set A to set B,
A=B)?
>
> Invertible? yes. Domain = range? No.
It said "all bijections have a function f' such that f'(f(x)) = x" and "for
every element of the codomain there is some element of the domain which maps
to it"
This means in the case of TimTyler's argument about 1 byte => 3 byte is a
bijection is false since not all single byte values can map to 3 bytes and
be invertible.
So either (this is talking about the BICOM vs CTR stuff) BICOM is a not
invertable and has this mapping, or it's invertable and not a bijection.
In other words. If every element of the 3-byte set (all 2^24 elements) had
an inverse in the 1 byte set (which is required for a bijection) then each
element of the 1 byte set would have to map to multiple values in the 3 byte
set (since the 3 byte set has a larger order this is a fundemental truth of
ordered numbers).
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: BBS implementation
Date: Sun, 03 Jun 2001 18:02:45 GMT
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I want to know how to initialze it from a key.
Do you already have a blum integer?
Just make a random integer X (between 1 and N) and use X^2 mod N as your
starting value.
Tom
>
> Tom St Denis wrote:
>
> > <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Where can I find some info on practical BBS implementation?
> >
> > Um, square an integer modulo a composite blum integer repeatedly and
output
> > the log log n lower bits
> >
> > What else do you want?
> >
> > Tom
>
>
>
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Large Number Math Package
Date: Sun, 03 Jun 2001 11:07:13 -0700
What is the .gz extension? How can I untar it on a PC?
Joe
Jeffrey Walton wrote:
> UBASIC:
> http://archives.math.utk.edu/software/msdos/number.theory/ubasic/.html
>
> link from Chris Caldwell's Prime Pages:
> http://primes.utm.edu/links/programs/large_arithmetic/
>
> "john Latala" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> : On Thu, 31 May 2001 [EMAIL PROTECTED] wrote:
> :
> : > I was wondering if someone could direct me to a big number crypto
> math library.
> : > Does one exist that contains all of the typical math operators, but
> also
> : > contains min, gcd, lcm, jacobi symbol, modular exponentialtion, mod,
> etc. which
> : > handle infinite precision numbers?
> :
> : There used to be a package called ubasic that was a BASIC interpreter
> : that supported extended precision math in all it's calculations. the
> : author of the package included two examples packages. One was various
> : odds and ends while the other was geared to number theory. I think
> that
> : did a couple of the things that you mentioned but it's been a while
> since
> : I looked at it so the memory is fading. I'm not sure if it's been
> updated
> : or not.
> :
> : The other alternative would be the GNU MultiPrecision math package
> called
> : GMP. See any GNU archive site. I think it also ships with most/all
> Linux
> : distributions too.
> :
> : --
> : john R. Latala
> : [EMAIL PROTECTED]
> :
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Large Number Math Package
Date: Sun, 03 Jun 2001 18:09:07 GMT
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What is the .gz extension? How can I untar it on a PC?
Eegad. I would suggest you learn how to use your comp before you try to
program something!
.gz is the gzip file extension.
if you want to untar something (in windows I presume, note that not all PCs
use winblows) try getting WinZIP or WinIMP (www.winimp.com)
Tom
>
> Joe
>
> Jeffrey Walton wrote:
>
> > UBASIC:
> > http://archives.math.utk.edu/software/msdos/number.theory/ubasic/.html
> >
> > link from Chris Caldwell's Prime Pages:
> > http://primes.utm.edu/links/programs/large_arithmetic/
> >
> > "john Latala" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > : On Thu, 31 May 2001 [EMAIL PROTECTED] wrote:
> > :
> > : > I was wondering if someone could direct me to a big number crypto
> > math library.
> > : > Does one exist that contains all of the typical math operators, but
> > also
> > : > contains min, gcd, lcm, jacobi symbol, modular exponentialtion, mod,
> > etc. which
> > : > handle infinite precision numbers?
> > :
> > : There used to be a package called ubasic that was a BASIC interpreter
> > : that supported extended precision math in all it's calculations. the
> > : author of the package included two examples packages. One was various
> > : odds and ends while the other was geared to number theory. I think
> > that
> > : did a couple of the things that you mentioned but it's been a while
> > since
> > : I looked at it so the memory is fading. I'm not sure if it's been
> > updated
> > : or not.
> > :
> > : The other alternative would be the GNU MultiPrecision math package
> > called
> > : GMP. See any GNU archive site. I think it also ships with most/all
> > Linux
> > : distributions too.
> > :
> > : --
> > : john R. Latala
> > : [EMAIL PROTECTED]
> > :
>
>
>
------------------------------
** 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
******************************
