Cryptography-Digest Digest #994, Volume #12 Tue, 24 Oct 00 14:13:01 EDT
Contents:
Re: Huffman stream cipher. (Richard Heathfield)
Re: BIOS password, will it protect PC with PGPDisk against tampering ? (Mack)
Re: Hypercube/FFT encryption (Mack)
Re: Huffman stream cipher. (SCOTT19U.ZIP_GUY)
Re: Huffman stream cipher. (SCOTT19U.ZIP_GUY)
Re: Using DH (Ichinin)
Re: Rijndael implementations (John Myre)
Re: Rijndael file encryption question. (Mike Rosing)
Re: Huffman stream cipher. (Richard Heathfield)
Re: Using DH (Mike Rosing)
Re: Huffman stream cipher. (Mok-Kong Shen)
Re: Works the md5 hash also for large datafiles (4GB) ? (John Myre)
Re: Rijndael file encryption question. (SCOTT19U.ZIP_GUY)
Re: Visual Basic (mdc)
Re: RSA codes (John Myre)
Re: GCHQ Challenge (John Myre)
----------------------------------------------------------------------------
Date: Tue, 24 Oct 2000 17:03:25 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Richard Heathfield) wrote in
> <[EMAIL PROTECTED]>:
>
> >> >That, sir, is incorrect; it /is/ possible and indeed relatively easy
> >> >to write code that is portable to the vast majority of machines and
> >> >compilers, and still possible (though less easy) to write code that
> >> >is universally portable.
> >>
> >> I do not think it is possible to write a scott19u version of
> >> C that runs on most machines.
> >
> >If that is true, then its usefulness is limited. Still, I doubt that
> >it's true.
>
> Again your lack of experience shows through. It is true!!
We'll see. Rome wasn't built in a day, you know.
> >> It just can not be easily done.
> >
> >That's an interesting claim. I'm almost tempted to take you up on it.
> >After all, it's not as if your obfuscation is deliberate.
>
> That is another lie common to pompous assholes.
Sir, you are very quick to call people names, and very quick to use foul
language. I hope you are also quick to apologise when it is appropriate.
> You have
> no intention of writting it so why do you even pretend you have
> the ability to do otherwise.
I have made no such claim, and I do not now make such a claim. But I do
not discount the possibility that I may make that claim in the future.
> Your lack of ability to even figure
> out how to get it to compile when you finally got a good complier
> shows me you lack the ability to do this kind of task.
How sweet. Perhaps I should buy a good book on C to help me. :-)
> I have ported
> earlier version of my code to SEL and MACs but that is when I had
> access to such machines so I could play with them. You need test
> machines to practice on. You can't write in some proper way and
> expect to run on all machines. It just is not reasonable
Perhaps not. But perhaps. It's not yet proven either way.
> To combine this with other thread I sometimes confuse right
> and left. What do you think the symbol ">>" means is it a right
> shift with sign carry or zero fill. Or is it machine dependent.
> So what is proper.
The behaviour of right-shift on a signed integer is undefined if the
value stored in that signed integer is negative. It is therefore wise to
restrict your shifting to unsigned integer types (and, in cryptology,
this restriction is no great hardship) - a right shift on an unsigned
integer type always leaves zero-bits in its wake.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: 24 Oct 2000 16:06:31 GMT
>----BEGIN PGP SIGNED MESSAGE-----
>
>Physical security is the most important one. It is the very good solution but
>will you ask your user to remove H/D from PC and WHAT ?
>
>- - ask them to take home ?
>- - move to central storage place ?
>- - another place ?
>
>How this solution could help in the normal time, after boot - up stage has
>been
>completed ?
>Would you ask user to take H/D when leaving temporarily her desk ?
>
>- From what I know, they have 2 x H/D in each PC, it could be not very
>convenient.
>
>
>On 19 Oct 2000, [EMAIL PROTECTED] (Guy Macon) wrote:
>>
>>Easy. Go to [ http://www.dirtcheapdrives.com/ ], click on "Dataport"
>>[ http://www.dirtcheapdrives.com/welcome_pages/dataport_w/index.html ]
>>and take your drive with you when you leave. You can even get a clean
>>drive to leave in there for the attacker tp waste time on.
>
>~~~
>This PGP signature only certifies the sender and date of the message.
>It implies no approval from the administrators of nym.alias.net.
>Date: Sat Oct 21 22:50:13 2000 GMT
>From: [EMAIL PROTECTED]
>
>-
Looking at the model used in various
government agencies might be helpful.
The hard drive must be removable
and locked in a secure location
when not in use.
Yes, that means lock it up when you
go to the bathroom.
The drive is also supposed to have
built in encryption of some kind.
Not software but hardware. They
appearently work only with a specific
controller. Unceratain as to whether
this means one and only one controller
or one type or brand of controller.
Generally I would say that the best
location is a central repository. If
the attacker is a dishonest employee
then the mode of attack may be simply
taking the drive home.
I think the model requires checking the
drive in and out each time the user leaves
their workstation. Not too clear on how
that works.
Some of this is fourth hand information
so if it seems a bit fuzzy that is why.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Hypercube/FFT encryption
Date: 24 Oct 2000 16:29:01 GMT
>
>On Mon, 23 Oct 2000 15:16:54 -0500, in
><[EMAIL PROTECTED]>, in sci.crypt James Felling
><[EMAIL PROTECTED]> wrote:
>
>>>
>>> PS to Ritter, in one of your docs, you say that with 1 plaintext /
>>> ciphertext pair, you can probably uniquely identify a DES key... I
>>> believe the actual number required is 3 pt/ct pairs.
>>>
>>
>><snip>
>>What you say is true in one sense, and what he says is true in annother.
>>3pt/ct is the MAXIMUM ammount required. However, typically 1pt/ct pair will
>be
>>enough to do so, 3 merely confirms it beyond the shaddow of a doubt.
>
>That depends on what size of shadow you need for doubt.
>
>There is no end to the abstract possibility that, at random, some
>false key will produce the desired first block transformation, that
>same key will produce the desired second block transformation, and so
>on. So even 3 pairs does not "confirm it beyond the shadow of doubt."
>There *is* no "beyond . . . doubt," there is just, very, very, very,
>very, very unlikely.
>
>In practice, none of this is an issue.
>
>---
>Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
>Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
>
>
I believe there is some literature that shows that DES can
only have one key which produces three given pairs. No I don't have
a specific reference, I may be wrong on this. And in general
It requires two pairs to confirm that you have the correct key.
However ciphertext may be substituted for a known pair if
the data structure is known. The analysis on that one is
more complex.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Huffman stream cipher.
Date: 24 Oct 2000 16:29:35 GMT
[EMAIL PROTECTED] (Richard Heathfield) wrote in
<[EMAIL PROTECTED]>:
>Runu Knips wrote:
>>
>> Richard Heathfield wrote:
>> > "SCOTT19U.ZIP_GUY" wrote:
>> > > >Here is the output I got:
>> > > >
>> > > >D:\alldata\dev\crypto\scott19u>gcc -W -Wall -ansi -pedantic
>> > > >scott19u.c In file included from scott19u.c:8:
>> > > I see your mistake. you should have used
>> > > gcc -O3 scott19u.c -o scott19u.exe
>> > > then it will work.
>> >
>> > You mean, "turn off all the warnings so that the compiler won't tell
>> > me how crap the code is, and turn off all the portability flags so
>> > that the compiler won't tell me that this code is as portable as
>> > Mount Everest"?
>>
>> Calm down.
>
>My dear chap, I'm not uncalm, I assure you. I know my choice of words is
>somewhat lyrical on occasion, but I'm no longer so naive as to get
>really upset over a Usenet article.
>
>> 'long long' is AFAIK part of the new ISO C standard.
>
>Yes, that's right. In due course, we'll be able to use it portably. But
>not quite yet.
>
>> And if
>> you want to use 64 bit integers, you HAVE to use the features of your
>> compiler, there is no fully portable solution which works with all
>> compilers yet.
>
>You're gonna love this. He aliases long long in the header file, but
>doesn't use the type /at all/ in the actual program, so it's a
>completely pointless departure from ISO C90.
>
>
I usually create a file of types un32 un64 and such so that
I can use them when the need comes up. When you create a type
the complier and linker do not use no wasted space by writting code
until and or unless they are used. Your are correct the version
of scott19u that I have out there does not use "long long" but
I still define that as a basic type in my .h file. I wished C
had types of UN64 or UN32 so one can relate the number of bits
used to the type but it does not.
The file DSTYPES.H is a common h file to many of my programs
that does not mean that every type in there is used by every program.
Just as when you commonly include STDIO.H much of what is included
is never used in the code that the included is in a given program.
It is a common C practice when one writes much code. Maybe you will
learn this when you get more experience.
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] (SCOTT19U.ZIP_GUY)
Subject: Re: Huffman stream cipher.
Date: 24 Oct 2000 16:40:41 GMT
[EMAIL PROTECTED] (Richard Heathfield) wrote in
<[EMAIL PROTECTED]>:
snip
>Sir, you are very quick to call people names, and very quick to use foul
>language. I hope you are also quick to apologise when it is appropriate.
>
I like to think I am. I am not like most of the pompous assholes
out there. But I guess I am an asshole I get plenty of email calling
me one.
>> You have
>> no intention of writting it so why do you even pretend you have
>> the ability to do otherwise.
>
>I have made no such claim, and I do not now make such a claim. But I do
>not discount the possibility that I may make that claim in the future.
>
>> Your lack of ability to even figure
>> out how to get it to compile when you finally got a good complier
>> shows me you lack the ability to do this kind of task.
>
>How sweet. Perhaps I should buy a good book on C to help me. :-)
I think that is a waste of time. JUst write code and play wiht
the machine your learn far more.
>
>> I have ported
>> earlier version of my code to SEL and MACs but that is when I had
>> access to such machines so I could play with them. You need test
>> machines to practice on. You can't write in some proper way and
>> expect to run on all machines. It just is not reasonable
>
>Perhaps not. But perhaps. It's not yet proven either way.
>
>> To combine this with other thread I sometimes confuse right
>> and left. What do you think the symbol ">>" means is it a right
>> shift with sign carry or zero fill. Or is it machine dependent.
>> So what is proper.
>
>The behaviour of right-shift on a signed integer is undefined if the
>value stored in that signed integer is negative. It is therefore wise to
>restrict your shifting to unsigned integer types (and, in cryptology,
>this restriction is no great hardship) - a right shift on an unsigned
>integer type always leaves zero-bits in its wake.
>
>
Does your precious long -W -p,,, whatever tell when your using
a signed integer with >> or what? Since if it doesn't why put the
extra crap on the gcc command line.
From reading your carfully chosen but misguided responsie I would
guess your a Gore supporter. Is that true. I would be willing to say
I was wrong if you anwser differently. I also not long ago apolojized
for saying what I felt when we so carefully bombed the chinese embassy
in Yugoslavia. I was sure it was part of a scheme bewteen the Clinton
Gore camp to give Twain back to Red China as part of the payoff of
Red Chinese money they took. But China has not yet invaded them so
I guess I may have been way off base.
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: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Using DH
Date: Tue, 24 Oct 2000 07:09:37 +0200
Hi.
Guess where the weak link is.
(Hint: attack is at the final Value modulo N transfer,
no matter how much expanding or hashing you do.)
> Also, does anyone know where I can find some tested *safe* parameters
> for DH >1024-bits??
There were some link refering to a list of common problems with
DH, but that link was unavailable for an external audience.
If anyone know what i'm talking about and have another link (as in
Public), at least i would appreciate it.
Regards,
Ichinin
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Date: Tue, 24 Oct 2000 11:10:43 -0600
Tim Tyler wrote:
<snip>
> I believe the issue under discussion is what terminology is desirable -
> not whether people understand the existing terms.
<snip>
Actually, those are the same. The only reason to change
the "official" meaning would be because too many people
don't understand it. Which is to say, "byte should mean
eight bits because most people already think so, anyway."
As another poster implied, this is not a technological
discussion, at all. It is another in a long line of
skirmishes over the proper use of language - should we
try to preserve the original meaning of a term, or allow
it to change? In this particular case, what term would
you suggest, if byte always means exactly eight bits, for
the concept for which "byte" was invented? Or do you
think that the concept is no longer relevant, and we can
simply forget it?
JM
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Rijndael file encryption question.
Date: Tue, 24 Oct 2000 12:23:38 -0500
ajd wrote:
> b) Save the entire final encrypted block before sending to Bob (so we save
> 112 bytes of encrypted data instead of 99). The problem here is that Bob
> doesn't know how long the original encrypted file was. When he decrypts he
> then gets:
> oh I do like to be beside the seaside.
> Oh I do like to be beside the sea.
> where the brass band pl�������������
>
> We have the whole original method but some extra stuff as well. For non-text
> files this could prove to be a problem. Do I use this method and send the
> file length to Bob as well or is there another way to get around the
> problem?
Fill the remaining block with extra known data. The IEEE standard says to fill
with 01, 0202, 030303, etc up to the number of bytes you've filled with. that's
binary, so you can make it ascii if you like: 1, 22, 333, 4444, etc.
That way you always send a correct multiple of block data bytes and it's pretty
easy to pick off the padding.
Patience, persistence, truth,
Dr. mike
------------------------------
Date: Tue, 24 Oct 2000 18:25:32 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
"SCOTT19U.ZIP_GUY" wrote:
>
> >> Your lack of ability to even figure
> >> out how to get it to compile when you finally got a good complier
> >> shows me you lack the ability to do this kind of task.
> >
> >How sweet. Perhaps I should buy a good book on C to help me. :-)
>
> I think that is a waste of time.
I bet you do.
> JUst write code and play wiht
> the machine your learn far more.
I might learn far more about the machine that way, but I wouldn't learn
as much about C.
<snip ostrich-like response to warnings>
> From reading your carfully chosen but misguided responsie I would
> guess your a Gore supporter.
Really? Gosh.
> Is that true.
I'm not really all that interested in discussing the local politics of a
foreign country in an international forum but, for the record, I am not
a Gore supporter. Neither do I support his opponent. I have nothing to
say, good or bad, about either of them, or about any foreign politician
- at least, not in sci.crypt, where the topic is cryptology, not
politics.
<snip>
I strongly recommend that we bring this subthread to an end, since it
bears very little relevance to the topic of the group in general or
Huffman stream ciphers in particular. If I get time to look at your
program more thoroughly, I will report the fact in a new thread with a
new subject line.
I expect you are one of these people who likes to have the last word so,
if you choose to reply to this thread, bear in mind that I won't follow
it up (I guess you could take that as licence to be as offensive as you
like, but I hope you don't).
Alternatively, surprise me, and let the thread die now.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Using DH
Date: Tue, 24 Oct 2000 12:31:58 -0500
George Gordon wrote:
>
> In using DH, if you:
>
> a) create a random 160-bit key, then
>
> b) expand that to 2K+ bits using RC4 or something,
>
> c) create a shared key using DH, then
>
> d) hash that to a 160-bit key using SHA1, and
>
> e) use that as your symmetric key.
>
> Is that OK??
Sure it's ok, but why? If you've got a 160-bit random key, why not
use it directly? You can use DH to exchange the session key. If it's
really random, why do all that other stuff?
>
> Also, does anyone know where I can find some tested *safe* parameters
> for DH >1024-bits??
With ECC you can send the 160 bit key using 325 bits.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Huffman stream cipher.
Date: Tue, 24 Oct 2000 19:45:14 +0200
Richard Heathfield wrote:
>
> [I presume, by the way, that <<< means either 'rotate left' or 'left
> shift a LOT* :-) ]
The symbol has been used to denote rotate left in the
literature. C standard unfortunately doesn't provide that
function which is present e.g. in Fortran.
M. K. Shen
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?
Date: Tue, 24 Oct 2000 11:28:39 -0600
Bryan Olson wrote:
<snip>
> Actually it's any non-negative, integral number of bits.
> From RFC 1321, "The MD5 Message-Digest Algorithm":
>
> In the unlikely event that b is greater than 2^64, then only
> the low-order 64 bits of b are used.
<snip>
Huh. Makes sense.
Has anyone considered whether this fact could be used in
finding a collision? Offhand, I don't see anything, but
maybe someone smarter does. Granted, a collision between
two "messages" that differed in size by 2^64 bits seems
hardly useful. (Although, as I understand it, the Devil's
contracts are reputed to be quite long.)
JM
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Rijndael file encryption question.
Date: 24 Oct 2000 17:38:54 GMT
[EMAIL PROTECTED] (Mike Rosing) wrote in
<[EMAIL PROTECTED]>:
>ajd wrote:
>> b) Save the entire final encrypted block before sending to Bob (so we
>> save 112 bytes of encrypted data instead of 99). The problem here is
>> that Bob doesn't know how long the original encrypted file was. When
>> he decrypts he then gets:
>> oh I do like to be beside the seaside.
>> Oh I do like to be beside the sea.
>> where the brass band pl�������������
>>
>> We have the whole original method but some extra stuff as well. For
>> non-text files this could prove to be a problem. Do I use this method
>> and send the file length to Bob as well or is there another way to get
>> around the problem?
>
>Fill the remaining block with extra known data. The IEEE standard says
>to fill with 01, 0202, 030303, etc up to the number of bytes you've
>filled with. that's binary, so you can make it ascii if you like: 1,
>22, 333, 4444, etc.
>
>That way you always send a correct multiple of block data bytes and it's
>pretty easy to pick off the padding.
>
>Patience, persistence, truth,
>Dr. mike
>
Actually this is a dumb method since what if the real file had
a ending likt 01 then how would you know not to toss it. No wonder
I never joined IEEE if this is there standard maybe we should wait
for the Europeans because this is plain stupid.
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] (mdc)
Subject: Re: Visual Basic
Date: Tue, 24 Oct 2000 17:42:10 GMT
On Mon, 23 Oct 2000 09:34:51 +0200, Ichinin <[EMAIL PROTECTED]> wrote:
>How is
>
>A)
> n * 2 = <<
> n / 2 = >>
> n mod 2 = extract bit state
>
>or
>
>B)
>Declare Function Rotl Alias Lib "CPlusPlus.DLL" (Byval Rotl_Data as
>Integer) as Integer
>(etc)
>
>hard to do in vb?
But in VB, integers are signed. If you're coding an algorithm that
uses 32-bit unsigned integer values, you have to either split your
values into high/low 16-bit values or overload all the integer
functions like mod to work with long or variant data types.
mdc
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: RSA codes
Date: Tue, 24 Oct 2000 11:49:11 -0600
"SCOTT19U.ZIP_GUY" wrote:
<snip>
> think there god just becuase they can speel
> better than me.
<snip>
Perhaps you meant "spiel"? :)
(As in, "the salesman's spiel was dazzling".)
JM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: GCHQ Challenge
Date: Tue, 24 Oct 2000 12:00:04 -0600
CiPHER wrote:
<snip>
> The hardest thing was actually _finding_ all the bits.
<snip>
Which was probably deliberate. Or at least, it would
be quite sensible to have done it deliberately, given
the purpose.
JM
------------------------------
** 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
******************************
