Cryptography-Digest Digest #474, Volume #12 Fri, 18 Aug 00 10:13:01 EDT
Contents:
Re: Best AES candidates ?? (Mark Wooding)
Re: OTP using BBS generator? (Mark Wooding)
Re: blowfish problem (Paul Schlyter)
Re: DES: Say it or spell it? (Newbie question) (Paul Schlyter)
Re: DES: Say it or spell it? (Newbie question) ("Sam Simpson")
Re: blowfish problem (Richard Bos)
Re: Not really random numbers ("ink")
Re: Unauthorized Cancel Messages (Ron B.)
Re: DES: Say it or spell it? (Newbie question) (Jim Reeds)
Re: Cracking RC4-40 in FPGA hardware ("Paul Morris")
Re: New Stream Cipher like SEAL (csybrandy)
Re: Not really random numbers (Mark Wooding)
Re: blowfish problem ("Michael Will")
Java Random Numbers ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Best AES candidates ??
Date: 18 Aug 2000 09:02:21 GMT
Vic Drastik <[EMAIL PROTECTED]> wrote:
> This is the second time someone has mentioned possible security
> problems with the Square cipher. Could you provide more detail , or
> give an online reference ?
I've not seen any analysis directed particularly at Square since the
original paper, but given the strong similarities between it and
Rijndael, the weaker key schedule, and the paper `Improved Cryptanalysis
of Rijndael' by Niels Ferguson, John Kelsey, Stefan Lucks, Bruce
Schneier, Mike Stay, David Wagner, and Doug Whiting (available from
http://www.cs.berkeley.edu/~daw/papers/rijndael-fse00.ps) I'd say it
looks really rather dodgy.
Can anyone see a reason this attack *doesn't* work against 8-round
Square?
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: OTP using BBS generator?
Date: 18 Aug 2000 09:13:38 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Mark Wooding wrote:
> >
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > > Sorry, doesn't this result of Vazirani and Vazirani conflict with the
> > > sentence 'There is no proven reduction in the other direction' above,
> > > or have I understood your text entirely in the wrong manner? Could you
> > > please say a bit more?
> >
> > You've misunderstood.
> >
> > We have QRP <=_P IFP, but we *don't* have IFP <=_P QRP. The BBS paper
> > shows QRP <=_P BBS. The V&V paper shows IFP <=_P BBS, which doesn't
> > contradict the previous statements: we have QRP <=_P IFP <=_P BBS.
> >
> > If someone had shown that BBS <=_P QRP then that would have been
> > interesting.
>
> Excuse me. Could you please explain your notation '<=_P'
> and IFP?
IFP is the Integer Factorization Problem. I believe that the usual
phrasing of this as a decision problem is: `Given an integer n and an
interval [i_0, i_1], does n have a factor in the interval?'
`<=_P' is a less-than-or-equal sign with a subscript `P'. It means
`poly-time reduces to'. In simple terms, it means `is as easy as'.
> Sorry, I like to repeat a question, for I doubt that I have fully
> understood the issue. If the main theorem does not involve cycle
> length and has firmly established the security issue, why does one (in
> particular BBS) has to bother to consider subsequently the cycle
> length question at all?
* It's interesting to mathematicians, and it keeps them off the
streets. This is important: have you ever seen a rampaging mob of
mathematicians? Not a pretty sight...
* Some people keep on bringing the subject up without any particularly
good reason. The security proof, such as it is, applies regardless
of any considerations about cycle lengths.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: 18 Aug 2000 11:56:45 +0200
In article <8nhl7p$[EMAIL PROTECTED]>,
Michael Will <[EMAIL PROTECTED]> wrote:
> Gergo Barany wrote:
>>Daniel Leonard <[EMAIL PROTECTED]> wrote:
>>> 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 */
>
> 7.8: I see code like
>
> char *p = malloc(strlen(s) + 1);
> strcpy(p, s);
>
> Shouldn't that be malloc((strlen(s) + 1) * sizeof(char))?
>
> A: It's never necessary to multiply by sizeof(char), since
> sizeof(char) is, by definition, exactly 1. (On the other hand,
> multiplying by sizeof(char) doesn't hurt, and in some
> circumstances may help by introducing a size_t into the
> expression.) See also question 8.9.
>
> References: ANSI Sec. 3.3.3.4; ISO Sec. 6.3.3.4; H&S Sec. 7.5.2
> p. 195.
>
>>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. 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.
A byte can also be narrower than 8 bits: the old CDC 6600 used 6-bit
bytes, and the almost as old DEC-10 used 7-bit bytes (both these
machines were word addressed machines with 60-bit and 36-bit words
respectively).
Of course, Standard C cannot be implemented on such architectures,
since Standard C requires a char to be at least 8 bits. Thus, to
implement C on e.g. the CDC 6600, either a char would have to be 6
bits, which violates Standard C, or else a char would have to be
different from a byte.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: DES: Say it or spell it? (Newbie question)
Date: 18 Aug 2000 11:57:10 +0200
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> DJohn37050 wrote:
>
>> DES is usually pronounced dezz.
>
> Since when? Everybody I know spells it out, just as we do
> with the other umpteen thousand acronyms we are plagued with.
I've never heard anyone do that. Everyone I've heard pronounce
"DES" did say it as one word.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: DES: Say it or spell it? (Newbie question)
Date: Fri, 18 Aug 2000 11:58:47 +0100
FWIW: My experience in academia (in the UK) is that it's pronounced
DEZZ, just as DJohn says...
--
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> DJohn37050 wrote:
> > DES is usually pronounced dezz.
>
> Since when? Everybody I know spells it out, just as we do
> with the other umpteen thousand acronyms we are plagued with.
------------------------------
From: [EMAIL PROTECTED] (Richard Bos)
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Fri, 18 Aug 2000 10:56:27 GMT
[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.
> 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.
Richard
------------------------------
From: "ink" <[EMAIL PROTECTED]>
Subject: Re: Not really random numbers
Date: Fri, 18 Aug 2000 13:30:47 +0200
Anthony Stephen Szopa wrote...
[SNIP]
>See you all in a month or three.
Is that a promise or a threat?
ink
------------------------------
From: Ron B. <[EMAIL PROTECTED]>
Subject: Re: Unauthorized Cancel Messages
Date: Fri, 18 Aug 2000 11:20:57 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
On 18 Aug 2000 04:58:57 GMT, [EMAIL PROTECTED] (Guy Macon) wrote:
>Ron B. wrote:
>
>>Yes, you are right. However, I did contact support and discover
>>that my "assumption" was wrong. I then notified the group of my
>>error (see posting you quoted).
>
>Of course you did. One only needs to look at the history of your
>posts to see that you are polite and interesting to read.
Egads! Perhaps I'm on the wrong newsgroup then (esp. the polite
part).
Seriously, thank you.
Ron B.
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOZ0cDAzUoy7OvTSOEQJIDQCdHtpp0GGpuK6cEpkVUWGlsMnMef0An0J8
4jm4pPlBm5l4TZu5/G0sLJqp
=j3rW
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Jim Reeds)
Subject: Re: DES: Say it or spell it? (Newbie question)
Date: Fri, 18 Aug 2000 12:09:57 GMT
Like Doug Gwyn, I spell out D. E. S., but almost everyone
else I seems to say "Dez". I think it's a generational
thing: us true old farts spell it out right, but newbies
have been calling it Dez for a couple of decades now.
How about XOR? I justabout flipped the first time I heard
it pronounced "ksor". And, for a while, the idiotic
word "malleable" (meaning, I suppose, "forgeable") was
pronounced and then spelled with 2 syllables, "mallable",
with the vowel sound of "cat". And that monstrosity,
residuosity. Psaugh!
--
Jim Reeds, AT&T Labs - Research
Shannon Laboratory, Room C229, Building 103
180 Park Avenue, Florham Park, NJ 07932-0971, USA
[EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360 8178
------------------------------
From: "Paul Morris" <[EMAIL PROTECTED]>
Subject: Re: Cracking RC4-40 in FPGA hardware
Date: Fri, 18 Aug 2000 13:36:42 +0100
The idea of the project is more of an engineering challenge rather than
economic practicality. Having said that, however, I would hope that my time
and hard work would not be completely academic. I was hoping that modern
microprocessor design techniques such as pipelining might provide more
crunching power than might otherwise be expected.
I am also considering the possibility of researching a different idea. This
device would contain a built in RNG which would produce keys for a suitable
cipher. This key would be stored within the device and protected from
removal by normal security safeguards (physical security of the device etc).
The device would produce an 'access' key which would enable
decryption/encryption of data using the 'data' key. I thought this might be
a useful device because of the fact that the actual key is fully random and
known to no-one except the device. Therefore the device is required for all
transactions which can provide more security for the organisation, since
access to a box can be usefully restricted. What does anyone think of this?
Anyway, as you can probably tell there are a lot of different routes I can
take. Depending on whether I want to focus on pure digital and FPGA work or
branch out into developing a RNG in anologue hardware etc.
Thanks for the input.
Regards,
Paul Morris
------------------------------
From: csybrandy <[EMAIL PROTECTED]>
Subject: Re: New Stream Cipher like SEAL
Date: Fri, 18 Aug 2000 09:01:38 -0400
> I don't have the algorithm in front of me but maybe you can design
> it so that superscalar processors can overlap the operations more.
>
> Also, the luts and rols don't necessarily need 2 cycles. I'm not
> sure how long they take on the p3/k6.
>
Well, I toyed with the algorithm some last night trying to rearrange
some of the instructions to get more speed. I tried to break up the
instructions to have computations performed during a memory access and
simple rearranging. The results: it slowed down. The only things that
I see that can speed this up without changeing the algorithm, which I
did not do, are replacing some of the operations with faster machine
instructions, such as the rotate or perhaps even some SIMD instructions,
and unrolling the inner loop ( for (j = 0; j < PASSES; j++) {...)
completely. The number of passes is static, as in not changed by the
program, so this will work.
I've just started learning assembly language programming, so I could not
test the effects of using assembly level instructions for improving the
speed of the algorithm. While I'm typing this message, I noticed that
the functions is called with this statement: sc1(buf, sizeof(buf)/16,
x, key);. If you replace the sizeof(buf)/16 with a static or
precomputed value it will run faster. I believe that certain
optimizations will do this automatically, but I feel it is good practice
to do this manually if you don't have to recompute the value all the time.
Anyway, enjoy!
csybrandy
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Not really random numbers
Date: 18 Aug 2000 13:22:38 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
... well, the word which springs to mind to describe what he wrote is
`drivel'. It's rather uhhh... special. I think this article needs to
be kept somewhere, as a reminder.
> "your method thends to need more keying data to achive a given
> level of entropy..." First I would like to say that OAP-L3 can
> match any level of entropy attainable by any other form of
> encryption, and can approach as closely as the user likes truly
> random entropy.
The entropy is random? That's not actually a good sign.
> One may choose to take the time and make the effort (both
> reasonable) knowing that there are no inherent constraints in
> the random number generation process therefore the security of
> the software is solely due to the random key length. There is
> no hope of factoring prime numbers for instance, there is no
> modulo 128 constraint, there is nothing that can be used to
> attack the process except brute force. (see below)
The phrase `no hope of factoring prime numbers' is a classic. (Hint:
there's a simple polynomial-time algorithm for enumerating all of the
factors of a prime number.)
What's a `modulo 128 constraint'? Sounds like you're spouting rubbish
to me.
> "Where is your proof of security?"
Important question.
> Let me take one process because one is representative of the others.
> First of all you need random user input. It is recommended that you
> shuffle a deck of cards with 56 cards in it to get four random
> sequences of the numbers 1 - 14. Or you can use numbered beans
> shaken in a bottle and withdrawn one by one for these sequences.
> Etc. (see Help Files at http://www.ciphile.com) These and similar
> random processes will generate the random user input.
>
> This one of several processes, will sequentially divide the
> 3,628,800 unique ten digit permutations of the digits 0 - 9 (the
> original encryption data file) into 14 files of 259,200
> permutations each.
>
> The permutations in each of these 14 files will be shuffled together
> one permutation from each file at a time according to the random 14
> number user input sequence thus generating a now reordered
> permutation file of the original 3,628,800 unique permutations.
>
> This process can be repeated using another randomly generated 14
> number sequence any number of times using this particular process
> or one of several others that are equally inherently unbiased to
> generate a subsequently reordered encryption data file.
>
> There are 3,628,800! (factorial) possible orderings of this
> encryption data file. Three thoroughly different ones are used in
> the current implementation to generate random numbers. (see Help
> Files) Therefore there are (3,628,800!)^3 possible orderings of
> three such files.
I've just done the maths. Your three files can contain about
2^{2^{27.7}} bits of entropy[1]. That's staggeringly huge. You suggest
obtaining the input entropy by shuffling decks of cards. Now, the decks
of cards I've seen tend to have 55 cards in them (that's 13 cards in
each of 4 suits, 2 (different) jokers and a bridge score card). I can
get 2^{2^{7.9}} bits of entropy out of shuffling such a deck.
Taking logs and dividing one by the other tells me that I need to
shuffle about 2^{20} decks of cards. That's about a million. Assuming
I get really good at this and manage to shuffle a deck of cards and type
in all of the cards into my computer in 10 minutes, this will only take
19 years to finish. And that's if I don't stop for lunch. Or dinner.
Or bedtime.
So please stop waffling about how big (10!)! is. It's irrelevant.
> The security of OAP-L3 comes from the fact that it does not take
> very many random user input sequences used in very many of the
> possible processes to make duplication of the final OTP files of
> random numbers practicably impossible to duplicate.
To make duplication ... impossible to duplicate? Wow. That sounds
impressive. Or is it codswallop? Yes, that's it.
> Furthermore, even if someone were to gain a significant portion of the
> random numbers generated, it would not be possible to duplicate the
> unknown random numbers because without the original key of random user
> input sequences and the processes used and the order in which they
> were used could anyone determine them since the final OTP random
> numbers are essentially the product of a one way series of processes
> with the known random numbers not providing you with sufficient
> information to generate the original key.
You were asked for a proof. This is hopelesly optimistic handwaving.
> All of this is explained in the Help Files.
>
> See you all in a month or three.
Can you make it longer, please?
[1] I had to use Stirling's approximation. I couldn't find a calculator
which would actually calculate \log\gamma of the appropriate thing
for me without exploding.
-- [mdw]
------------------------------
From: "Michael Will" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Fri, 18 Aug 2000 09:17:47 -0400
Gergo Barany wrote:
> 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
Thanks to all who responded. Even after reading here off and on for
years I missed that one. I was even under the impression that the
term 'byte' was deliberately avoided to avoid confusion, but I now
stand corrected on both counts.
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.)
- Michael
>In this vale
>Of toil and sin
>Your head grows bald
>But not your chin.
> -- Burma Shave
Mom's favorite:
Is he lonesome
Or just blind?
The guy who drives
Too close behind
-- Burma Shave
------------------------------
From: [EMAIL PROTECTED]
Subject: Java Random Numbers
Date: Fri, 18 Aug 2000 13:38:59 GMT
Java implementation of Random Number Generator.
Algorithm description and Java source code can
be found at www.alex-encryption.de
Regards.
Alex.
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
******************************
