Cryptography-Digest Digest #492, Volume #12 Sun, 20 Aug 00 20:13:00 EDT
Contents:
Re: OTP using BBS generator? (D. J. Bernstein)
Re: DES: Say it or spell it? (Newbie question) (D. J. Bernstein)
Re: Question on Decorelation Theory (Mok-Kong Shen)
Re: How Many? (John Savard)
Hidden Markov Models on web site! (John Savard)
our features
Re: blowfish problem ("Trevor L. Jackson, III")
Re: blowfish problem ("Trevor L. Jackson, III")
Re: Bytes, octets, chars, and characters ("Trevor L. Jackson, III")
Re: blowfish problem ("Trevor L. Jackson, III")
Re: Question on Decorelation Theory ([EMAIL PROTECTED])
Re: blowfish problem ("Trevor L. Jackson, III")
Re: How Many? (David A. Wagner)
Re: our features ([EMAIL PROTECTED])
Re: blowfish problem (Chris Torek)
Re: blowfish problem (Chris Torek)
Re: 1-time pad is not secure... (Tim Tyler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: OTP using BBS generator?
Date: 20 Aug 2000 20:28:21 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
> Make N large enough that factoring N is impractical.
Where do people get this idea? If you want to apply the theorems, you
need _much_ larger values of N.
Consider, for example, the Alexi-Chor-Goldreich-Schnorr theorem, which
tells you how to factor N using 10^54 (lg N)^3 applications of an
algorithm that has a 1/1000 chance of seeing a pattern in a billion bits
produced by a BBS generator mod N. The theorem doesn't say that
predicting the generator is as hard as factoring N; it allows a ratio of
speeds as large as 10^54 (lg N)^3.
This tells you nothing if you merely assume that the attacker needs
practically forever to factor N. You have to assume that the attacker
needs 10^54 (lg N)^3 times practically forever. That assumption is false
if N has, say, 3000 digits.
---Dan
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: DES: Say it or spell it? (Newbie question)
Date: 20 Aug 2000 20:30:40 GMT
Sander Vesik <[EMAIL PROTECTED]> wrote:
> Unlike AES, for example.
Ah-yes?
---Dan (who says Dee Eee Ess)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Question on Decorelation Theory
Date: Sun, 20 Aug 2000 23:53:57 +0200
[EMAIL PROTECTED] wrote:
>
> When a function is 1-wise decorrelated such as F(x) = x + k, you need
> only one input to begin a simple attack on it.
Your terminology is new to me. Could you please give a
reference where the term 1-wise decorrelation appears?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: How Many?
Date: Sun, 20 Aug 2000 21:42:51 GMT
On Sun, 20 Aug 2000 12:22:50 -0700, "John A. Malley"
<[EMAIL PROTECTED]> wrote, in part:
>"Trevor L. Jackson, III" wrote:
>> Neither of them cover masking with noise (steganography).
>Actually, transposition and substitution do cover steganography.
Only in the sense that substitution covers transposition. Hiding trees
with a forest doesn't involve changing the order of the trees, or
replacing a birch with an elm.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Hidden Markov Models on web site!
Date: Sun, 20 Aug 2000 21:47:56 GMT
Having heard from some posts that the concept of "Hidden Markov
Models" is relevant to cryptanalysis, I did some web searching, and
gained enough understanding to put a partial introduction on my web
page at
http://home.ecn.ab.ca/~jsavard/co041003.htm
This introduction only goes up to the Viterbi algorithm; I did not
understand such matters as Baum-Welch estimation well enough to
attempt to describe them, but I did note the name to assist those
seeking to do further reading. Also, since Kullback-Leibler distance
(between probability distributions - related to Friedman's chi test)
was mentioned, I checked, and yes, that was Solomon Kullback, among
those who broke PURPLE.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: <[EMAIL PROTECTED]>
Subject: our features
Date: Sun, 20 Aug 2000 23:03:12 +0100
Reply-To: <[EMAIL PROTECTED]>
Unlike other email providers www.hacker.am is well known for it's excellent
technical support. Your queries will be answered by a qualified technician
before you even check your email again. Quite often they're answered in less
that an hour. And if your problem can't be solved by email you can always
call our 24/7 Toll Free telephone support centre where our staff will be
delighted to help you.
Our web-based email interface is highly sophisticated and runs on lightning
fast, super cooled servers with multiple backbone connections with a 24 hour
technical team.
We exercise a zero-tolerance Spam policy and will keep ALL your details
completely confidential (as specified in Terms & Conditions).
And with a specially personalised domain name and a high availability of
usernames it really is worth trying out.
Give it a go >> www.hacker.am
------------------------------
Date: Sun, 20 Aug 2000 18:05:36 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Gergo Barany wrote:
> Daniel Leonard <[EMAIL PROTECTED]> wrote:
> > I do not want to be rude, but there are some "errors" in your code.
>
> I do not want to be rude, but your news software posts in some
> funky "Quoted-Printable" encoding. It makes your posts hard to read
> because it replaces many characters such as '=' with a code like
> "=<hex>", where <hex> is a character's ASCII code in hexadecimal.
> This stinks, please turn it off.
>
> > On 17 Aug 2000, John Hascall wrote:
> > > =09out =3D malloc(inLen * 2 + 1);
> >
> > shouldn't it be:
> > out =3D malloc((inLen * 2 + 1) * sizeof(char));
> > /* a char could be more than 1 byte */
>
> No, a char is always one byte in C.
No it's not. A character is the minimum unit of addressability, which may be
other than a byte. Espcially on older machines, making this assumption is an
error.
------------------------------
Date: Sun, 20 Aug 2000 18:09:26 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Gergo Barany wrote:
> Michael Will <[EMAIL PROTECTED]> wrote:
> > Gergo Barany wrote:
> >
> > >No, a char is always one byte in C.
> >
> > No, sizeof(char) is always 1 in C.
> >
> > These are not two ways of saying the same thing.
>
> Actually, they are. This topic has been beaten almost to death
> several times in comp.lang.c, but since sci.crypt is watching, I'll
> kick it a little more when it's down.
>
> > A char can be wider
> > than 8 bits, but even then sizeof(char) == 1 by definition. It may
> > seem strange at first, but it is true.
>
> It does not seem strange to me, and I completely agree. I know that
> the terms "byte" and "octet" are not the same. I think we both agree
> that an octet is a group of 8 bits; a byte, however, is something
> else. The N869 draft standard (available from
> http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n869/ and AFAIK
> identical in its normative contents to the actual standard) has
> these things to say:
>
> 3. Terms and definitions
>
> 3.4
> [#1] byte
> addressable unit of data storage large enough to hold any
> member of the basic character set of the execution
> environment
>
> 3.5
> [#1] character
> bit representation that fits in a byte
>
> So, a char fits into a byte.
>
> 5.2.4.2.1 Sizes of integer types <limits.h>
>
> [#1] The values given below shall be replaced by constant
> promotions. [...] Their implementation-defined values shall be
> equal or greater in magnitude (absolute value) to those
> shown, with the same sign.
>
> -- number of bits for smallest object that is not a bit-
> field (byte)
> CHAR_BIT 8
>
> -- maximum value for an object of type unsigned char
> UCHAR_MAX 255 // 28**-1
>
> A char must be at least 8 bits.
No.
On a modern, standards-compliant system a byte is at least 8 bits, but I've
worked on three distinct system architectures where a byte was less than 8
bits.
If you want to state an invariant, just qualify it with the domain within
which the invariance is valid.
------------------------------
Date: Sun, 20 Aug 2000 18:15:10 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
"Bruce G. Stewart" wrote:
> David Hopwood wrote:
>
> > > And to show that this is not just crazy C programmers talking, see
> > > this (admittedly non-normative) quote from the Jargon File:
> > >
> > > byte /bi:t/ n.
> > >
> > > [techspeak] A unit of memory or data equal to the amount used to
> > > represent one character;
> >
> > But, this definition is wrong, because C 'char' != character in general.
> > It's very common for 1, 2, 4, or variable numbers of octets or bytes to
> > be used to represent a character (both in C programs, the terminology
> > used in the C specs notwithstanding, and in other contexts). The use of
> > the word "character" to mean anything other than a unit of text (such as
> > a symbol, letter, etc., or possibly a control code), should be strenuously
> > resisted; characters are *not* units of storage.
>
> Well, heck, it just says the amount to represent one character, not the
> amount to represent any character, so variable-length mbcs codes could
> get off the hook on a technicality.
Not quite. We don't refer to multi-character character sequences, but
multi-byte character sequences. The leading byte of an MBCS character is not a
character. It is part of a character.
Otherwise we're using Humpty Dumpty speech, and we can refer to the leading bit
as a character ... in binary of course.
------------------------------
Date: Sun, 20 Aug 2000 18:19:35 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Richard Bos wrote:
> "Michael Will" <[EMAIL PROTECTED]> wrote:
>
> > After all these years I see there's always something new to learn.
> > I should go check my K&R to see if I should have known this from the
> > very start. (Yes, the original. The one we had to carry to school
> > uphill in the snow both ways, etc.)
>
> No, you shouldn't. It's quite possible that the word byte is used
> differently in K&R. However, that doesn't matter in the least, because
> since 1989, the C language has been defined by the ISO standard, not by
> K&R.
No. There isn't one C language.
There is ISO 1989 C and there is K&R C. I have and use compilers of both
flavors. This millennium even.
Check how many currently shipping compilers have a K&R switch. Last time I
looked at Borland's PC compiler they had four different varieties of C, ISO
and K&R being two of them.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Question on Decorelation Theory
Date: Sun, 20 Aug 2000 22:10:49 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] wrote:
> >
> > When a function is 1-wise decorrelated such as F(x) = x + k, you
need
> > only one input to begin a simple attack on it.
>
> Your terminology is new to me. Could you please give a
> reference where the term 1-wise decorrelation appears?
In the paper "Provably Security for Block Ciphers by Decorrelation" by
Serge Vaudenay. Page 5, Section 2 "Basic Constructions" and I quote
"Perfect 1-wise decorrelation is easy to achieve when the message-block
space M is given a group structure. For instance we can use C(x) = x +
K where K has a uniform distribution in M."
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sun, 20 Aug 2000 18:22:43 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Richard Bos wrote:
> [EMAIL PROTECTED] (Paul Schlyter) wrote:
>
> > In article <8nhl7p$[EMAIL PROTECTED]>,
> > Michael Will <[EMAIL PROTECTED]> wrote:
> >
> > > Gergo Barany wrote:
> > >>No, a char is always one byte in C.
> > >
> > > No, sizeof(char) is always 1 in C.
> > >
> > > These are not two ways of saying the same thing.
>
> They are, as has been said upthread. C byte != hardware byte.
>
> > A byte can also be narrower than 8 bits:
>
> Not in C, it can't.
Sure it can. The C programs that were written with C compilers on machines
with CHAR_BIT < 8 are still C programs. They just aren't C99 programs.
>
>
> > Of course, Standard C cannot be implemented on such architectures,
> > since Standard C requires a char to be at least 8 bits.
>
> Yes, it can; all it needs is that a logical C byte is not the same as a
> hardware byte. This is less strange than it sounds, and could even occur
> today, for example on a system where the standard char (and therefore C
> byte) is a Unicode character, and thus 16 bits wide, even if the
> hardware byte is 8 bits.
> On a system where a hardware byte is 6 bits, I'd expect a char (and thus
> a byte) to be 12 bits in C, but of course it could even be 8 bits,
> though that would require a lot of inefficient en- and decoding.
Agreed.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: How Many?
Date: 20 Aug 2000 15:29:22 -0700
I agree that complication can often be used to enhance security.
At the same time, it is worth remembering the usual argument against
unnecessary complications: complexity makes gaining confidence in a
design substantially more costly. Given that we, the open community,
are working with very limited cryptanalysis resources, this is is a
reasonable concern.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: our features
Date: Sun, 20 Aug 2000 22:26:43 GMT
We got your message the first time. Stop messaging this group about it.
Tom
In article <8npkil$boo$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
> Unlike other email providers www.hacker.am is well known for it's
excellent
> technical support. Your queries will be answered by a qualified
technician
> before you even check your email again. Quite often they're answered
in less
> that an hour. And if your problem can't be solved by email you can
always
> call our 24/7 Toll Free telephone support centre where our staff will
be
> delighted to help you.
> Our web-based email interface is highly sophisticated and runs on
lightning
> fast, super cooled servers with multiple backbone connections with a
24 hour
> technical team.
> We exercise a zero-tolerance Spam policy and will keep ALL your
details
> completely confidential (as specified in Terms & Conditions).
> And with a specially personalised domain name and a high availability
of
> usernames it really is worth trying out.
> Give it a go >> www.hacker.am
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Chris Torek)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Sun, 20 Aug 2000 22:50:23 GMT
>Gergo Barany wrote:
>>... The N869 draft standard ...
[large quote snipped]
>>A char must be at least 8 bits.
In article <[EMAIL PROTECTED]>
Trevor L. Jackson, III <[EMAIL PROTECTED]> writes:
>No.
>
>On a modern, standards-compliant system a byte is at least 8 bits, but I've
>worked on three distinct system architectures where a byte was less than 8
>bits.
>
>If you want to state an invariant, just qualify it with the domain within
>which the invariance is valid.
The problem here is that this is being cross-posted to both
comp.lang.c and sci.crypt. Over in comp.lang.c, "the domain" is
"the C language as standardized by X3.159-1989, 9899-1990, and
9899-1999". In all of those, a "byte" is just a "char" and it has
at least 8 bits.
Pre-ANSI C is also reasonably on-topic, but is so rare (relatively
speaking) that it should be qualified. If you mean "I used a C
compiler back before there was a C standard and it happened to have
six-bit `char's", well, that kind of thing was one reason there
are C standards now. (Incidentally, the C I know of on the Univac,
where 6 and 9 bit "bytes" were common, actually used 9 bits for
"char". A number of other oddball machines throughout the 1980s
had 9 or 10 bit bytes in their C systems. I am not aware of any
historical C compilers that used fewer than 8 bits, though.)
If you are posting from sci.crypt, you could well be using something
other than the C standards' weird definitions of "byte".
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA, USA Domain: [EMAIL PROTECTED] +1 510 234 3167
http://claw.bsdi.com/torek/ (not always up) I report spam to abuse@.
------------------------------
From: [EMAIL PROTECTED] (Chris Torek)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Sun, 20 Aug 2000 22:56:10 GMT
>>[EMAIL PROTECTED] (Paul Schlyter) wrote:
>>>A byte can also be narrower than 8 bits:
>Richard Bos wrote:
>>Not in C, it can't.
In article <[EMAIL PROTECTED]>
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
>Sure it can. The C programs that were written with C compilers on machines
>with CHAR_BIT < 8 are still C programs. They just aren't C99 programs.
Repeating this assertion does not make it true. "A byte is a char
and a char is a byte. The Standard is odd but by def. it is right!"
C89 (X3.159-1989) and the essentially-identical ISO 9899-1990 define
"byte" in the same way, and have the same constraints: CHAR_BIT must
be at least 8.
(I would be curious to know, though, if there were any pre-ANSI C
compilers that used fewer than 8 bits for a "char".)
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA, USA Domain: [EMAIL PROTECTED] +1 510 234 3167
http://claw.bsdi.com/torek/ (not always up) I report spam to abuse@.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Reply-To: [EMAIL PROTECTED]
Date: Sun, 20 Aug 2000 22:53:44 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: The relevant experiments set up a binary outcome:
: Go or No Go. If the underlying randomness were of the ordinary
: type, a Go would result; if the underlying randomness could not
: be of the ordinary type, a No Go would result. The results were
: invariably No Go, i.e. ordinary statistical randomness (resulting
: from incomplete information about detailed lower-level behavior)
: was definitely ruled out. [...]
Basically, above you /appear/ to be talking about an experiment which
would distinguish the output of *any* PRNG from a real RNG. As you should
be well aware, there's no such experiment.
Your description is /extremely/ vague, and I'm not sure which experiments
you're talking about - since no known experiment appears to fit your
description exactly.
However the ones that appear to /best/ fit the description appear not to
disprove the hypothesis that the universe is deterministic, but to
disprove the hypothsis that interactions between particles are local.
This result sometimes gets billed as refuting local hidden variable
theories (which it pretty much does). However it doesn't say whether
the universe is deterministic or not, it says whether the universe
exhibits behaviour which is local.
The question of - given the fact that particles can interact with other
particles apparently spontaneously over great distances - whether
the interactions have a deterministic basis, or a basis that includes
random events is an independent issue.
: This means that no amount of future refinement *can* determine any more
: detailed description.
By the time we get to here, you appear to me to have gone off the rails.
There's no such experiment that conclusively demonstrates that randomness
is present - nor could there possibly be.
Even /if/ the laws of the universe appeared totally deterministic, it
would not be possible to experimentally rule out the possibility that
minor effects which nobody had noticed were "fundamentally random".
Conversely, no matter /how/ random things appear, it's never possible to
absolutely rule out there possibility of an underlying deterministic
explanation, which nobody has found yet.
To my eyes, science is not in either position - nor will it be until
all observed phenomena fit into our scheme of proposed laws.
>From what science currently knows, it's *quite* possible our universe
exists as a simulation inside a large, deterministic computer.
It amuses me to think that some people feel they can completely dismiss
the idea that the universe is deterministic on the basis of our current
knowledge of physics.
We don't actually know what the laws of physics are. It even currently
seems possible that the laws of physics cannot be finitely expressed
by embodied organisms - so we'll never actually know what the laws of
physics are.
It might be fun to speculate on whether any ultimate laws that /might/
one day be found will be deterministic or include random elements - but
today, nobody can really say, one way or the other.
However, this idea has probably been tossed around enough for today on
sci.crypt. IIRC, we've had essentially this very discussion before.
I obviously failed to convince you - and the arguments you have
presented don't appear to me to make any difference to my views.
I tentatively suggest calling it a day. Perhaps if new arguments can
be offered that would be useful - but I'm beginning to doubt that
repeating our positions any further will actually help to resolve our
differences.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
** 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
******************************
