Cryptography-Digest Digest #863, Volume #11 Fri, 26 May 00 08:13:01 EDT
Contents:
Re: Short Secure Serial Numbers (wtshaw)
Re: Retail distributors of DES chips? (Mark Wooding)
Re: AES final comment deadline is May 15 (Mark Wooding)
Re: Short Secure Serial Numbers (Mark Wooding)
PGP wipe how good is it versus hardware recovery of HD? (Lee Herfel)
Re: AEES Advanced ([EMAIL PROTECTED])
MD5 win32 / linux compatibility ("Matt Farnell")
Re: Chosen Plaintext Attack (Raphael Phan)
Re: Another sci.crypt Cipher (tomstd)
Re: MD5 win32 / linux compatibility (Mark Wooding)
Re: OAP-L3: Version 5.x Revealed (tomstd)
Re: PGP wipe how good is it versus hardware recovery of HD? (tomstd)
Re: PGP wipe how good is it versus hardware recovery of HD? (Tom McCune)
Re: MD5 win32 / linux compatibility (Runu Knips)
Re: Base Encryption: Revolutionary Cypher (Tim Tyler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Short Secure Serial Numbers
Date: Fri, 26 May 2000 01:34:31 -0600
In article <01bfc633$ac206860$[EMAIL PROTECTED]>, "Rick Heylen"
<[EMAIL PROTECTED]> wrote:
> I am trying to find a solution to the following problem.
> We have a serial number which the user types in (so it can't be too long).
> The serial number contains some information like a product ID, user number
> etc with a total information content of about 96 bits and 40 bits of
> "checksum" with the idea being that for all possible information contents,
> there is only one valid checksum and that in order to find a valid serial
> number, an attacker would have to test on average 2^39 possibilities.
> The code that verifies the serial number is public but we'd still like it
> to be time-consuming to generate different valid serial numbers.
> Normal public key cryptography would be suitable except that the message
> size for the system to be secure would be longer than what a user would be
> happy to type in.
> Has anybody got any ideas?
>
> Richard
One algorithm is one of mine, which strongly encrypts strings. Let's look
at one example: The base character set used here has 40 characters. Only
you need to have the key, and, no, it cannot be deduced by anyone else.
Using an unspecified generic key for test purposes:
Pt: richard richard 12345 12345
Ct: (one of 39^5 possibilities for the same Pt with the same keys)
N7KS3 1W2XM 9O1IO 9S2FY E1K/, CQ?YT PE1X
Some more equivalents:
8YMRF PB?HW ?W8=B KKO9L KLP94 KRH18 RGM.
OYTR8 LPDDV L11U/ .N1E2 W5N4K R/G1Q 7I8M
Don't equate the 39^5 with your 2^39, as you are talking about only one
symmetric result. The keyspace in my example here is (39^5)+34(2^159.2).
Brute force that when pigs spout wings and fly.
What I am advocating is overkill, but why not the best as easy as doing it
all wrong.
You know the key, you decrypt the string to get your internal reference
numbers. Hey, this is even good enough to make revocable identification
numbers since you just record and issue another that decrypts to the same
plaintext information.
The system even allow you to catch most minor entry errors, and recover,
something unheard of.
The problem with most schemes is that they demand lots of headroom that is
inefficiently used. I add a little length to the string for all the good
reasons, security, security, security. But, doing it right is not
politically correct; and, they groaned, "How do we expect to break it when
we want to."
If the government can find security as more than a passing fancy, perhaps
it is ready for strong encryption to be widespread too.
--
Secrets that are told or available are not secrets any more, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Retail distributors of DES chips?
Date: 26 May 2000 08:34:03 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
> Then with a single chosen plaintext, the key is revealed. Assuming the
> backdoor plaintext is chosen randomly, no amount of testing that takes
> less than 2^63 expected work will find it.
True. Bleugh.
Moral: make sure that everything which does cryptography for you is
trustworthy.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: AES final comment deadline is May 15
Date: 26 May 2000 08:40:04 GMT
Kenneth Almquist <[EMAIL PROTECTED]> wrote:
> In the NIST implmenetations, the cost of changing a key is small
> but nonzero for Serpent and Twofish, because some time is required
> to calculate the subkeys for the first round.
For Twofish, the process which generates the round keys is extremely
similar to that which processes the data, and the two are mixed after
extremely similar operations are performed on each. The two can be
performed in parallel, and the key material is ready at just the right
time.
This assumes that the RS matrix multiplication to generate the S array
can be done cheaply. I don't think this is unreasonable.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Short Secure Serial Numbers
Date: 26 May 2000 08:50:54 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
> I'm not sure that it would be all that long. A discrete-log
> (e.g. DSA) signature would require a 2t + m bit serial number, where
> 2^t is the security level, and m is the number of bits of information
> encoded.
>
> For example, if you need a 2^56 security level and 96 bits of
> information, that would make a 208-bit serial number, which is 41
> characters in base 36 (i.e. 0-9a-z) encoding. (A 2^40 security level
> works out as 35 characters.
Umm... A DSA signature is two numbers each the size of the parameter q.
If q is approximately 2^2t, then the difficulty of computing discrete
logs in the q-order subgroup is O(2^t). (I'll assume that p is large
enough to make use of the NFS to solve discrete logs infeasible, since
its size affects only the size of the public key, not the signature.)
So you need signatures with size 4t + m, not 2t + m. 40-bit security
then gives you a 256-bit signed message, and a 50-character base-36
string. 56-bit security gives you 320-bit messages, or 62-character
base-36 strings.
-- [mdw]
------------------------------
From: Lee Herfel <[EMAIL PROTECTED]>
Subject: PGP wipe how good is it versus hardware recovery of HD?
Date: Fri, 26 May 2000 08:56:41 GMT
I have a program called shredder which I believes overwrites a file 7
times with random data to try and prevent hardware recovery of deleted
files aka the story in the WSJ. Does PGP wipe function do this or does
it only overwrite once?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AEES Advanced
Date: Fri, 26 May 2000 09:09:42 GMT
Paul,
Thank you for your tip.
It is a very good idea.
I will try to convert all DOC files in PDF and publish them in my web
till 27/05/200.
Best regards.
Alex.
In article <N2gX4.60188$[EMAIL PROTECTED]>,
"Paul Pires" <[EMAIL PROTECTED]> wrote:
> I followed the link and downloaded your description of the
algorithm in
> MS Word format.
> I was a little troubled to find that your file has active Macros
in it.
> I am not sophisticated enough to determine if it is toxic so I just
won't
> read it.
> What's wrong with PDF?
>
> Paul
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Matt Farnell" <[EMAIL PROTECTED]>
Subject: MD5 win32 / linux compatibility
Date: Fri, 26 May 2000 17:51:22 +0800
Any help would be much appreciated. Here's the problem
I'm using an MD5 c++ class to basically hash files. When using this MD5 code
I
get a certain output. I can get this same output by using someone else's
win32 MD5 command line utility. Therefore this confirms that the result must
be correct as two different sources resulted in the same 16 byte output.
The problem I have is when I compile md5 source on linux I get another 16
byte
output which does not equal my hash result using windows. I am hashing the
exact same file. I have also used two different linux MD5 sources that give
the same result as each other although still different to the windows
result. I have also compiled the linux source on both a MIP's and intel
based system and the results are the same as each other although different
to windows.
Am I doing or not understanding something fundamentally obvious ?
Regards,
MAtt
------------------------------
Date: Fri, 26 May 2000 18:16:33 +0800
From: Raphael Phan <[EMAIL PROTECTED]>
Subject: Re: Chosen Plaintext Attack
Matthew,
[EMAIL PROTECTED] wrote:
> Here you go. This code is a bit sloppy but should give you a good
> start. Have fun.
Thank you for your reply..
Raphael
" Contentment is not the fulfilment of what you want, it is the
realization of how much you already have. "
" When you were born, you cried and the world rejoiced.
Live your life in such a manner that when you die,
the world cries and You rejoice... "
------------------------------
Subject: Re: Another sci.crypt Cipher
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 26 May 2000 03:24:50 -0700
In article <8gkq7v$bkr$[EMAIL PROTECTED]>, matthew_fisher@my-
deja.com wrote:
>In article <[EMAIL PROTECTED]>,
> tomstd <[EMAIL PROTECTED]> wrote:
>> The cipher I was talking about earlier was not broken by my
>> attack because I used an invalid model (counting sboxes). So
I
>> updated my paper, cleaned up the source code and voila.
>>
>> The rerefence source is at
>>
>> http://www.tomstdenis.com/tc1ref.c
>>
>> And the paper in word97 format (sorry I can't get to the TOM
>> site to make it into .ps or .pdf format) here
>>
>> http://www.tomstdenis.com/tc1.doc
>>
>> I made some observations but I have yet to break the cipher.
>>
>> Tom
>
>Tom,
>
>Just a quick look. There is a class of 2^32 weak keys. When
all four
>input bytes are the same, the slide attack will be useful or so
it
>appears. GOST also has this property.
The chance of getting these keys is 2^-96 right? Hmm I can live
with that. Think I should include the round counter
to 'counter' the weak keys?
Thanks for looking at my cipher.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: MD5 win32 / linux compatibility
Date: 26 May 2000 10:29:30 GMT
Matt Farnell <[EMAIL PROTECTED]> wrote:
> Am I doing or not understanding something fundamentally obvious ?
In summary:
* You have your implementation A of MD5. You have independent reference
implementations of MD5 W and L on Windows and Linux.
* You have a test file F. A(F) = W(F) on Windows; A(F) = L(F) on
Linux. However, W(F) != L(F).
My conclusion is that the file either is or appears to be different on
Linux. My suspicion is that this is to do with the different formats of
text files between the two operating systems. Ensure that the file is
transferred and read by all pieces of software in binary mode.
-- [mdw]
------------------------------
Subject: Re: OAP-L3: Version 5.x Revealed
From: tomstd <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Date: Fri, 26 May 2000 03:29:32 -0700
In article <[EMAIL PROTECTED]>, Anthony Stephen
Szopa <[EMAIL PROTECTED]> wrote:
>OAP-L3: Version 5.x Revealed
>
>(Both OAP-L3 Version 4.x and OAP-L3 Version 5.x are patent
pending
>under two separate patent applications.)
>
>For the serious amateurs and the professionals, OAP-L3 Version
5.x is
>well on its way to becoming fully developed.
>
>I am not going to discuss the implications of this new OAP-L3
Version
>5.x here in this news group at this time.
>
>But you can see it in table form with text explanations by
going to
>http://www.ciphile.com
>
>Click on the What's Ahead web page from the Table of Contents.
>
>At the bottom of the What's Ahead web page you will find two
>hyperlinks: "Version 5.0 Tables" and "Version 5.0 Table Text".
>
>The hyperlink "Version 5.0 Tables" will bring up a web page
with four
>example tables describing the preferred embodiment of Version
5.0, and
>three alternative embodiment table examples.
>
>The hyperlink "Version 5.0 Table Text" will provide a
description of
>the tables and their operation.
>
>I will say this much: some of you have expressed concern that
the
>efficiency of OAP-L3 leaves something to be desired.
>
>With OAP-L3 Version 5.x, only one person need the full
>implementation with an executable file near 2MB. This person
>would be responsible for creating the data files (the table
data
>files) used in the encryption / decryption process.
>
>The other person only needs to be supplied with software that
>only encrypts and decrypts messages using such a table. I
guess
>that this executable file need only be about 50KB or maybe less
(for
>a windows executable.)
>
>So, using a table such as Table 4 with 120 rows, it would be
6942
>bytes long (uncompressed), and this table could generate about
3E12
>(maximum) random digits.
>
>The software and the data file (a data table) could be kept on
a
>floppy disk. And when the software is run, it could be read
>directly from this floppy disk and loaded directly into RAM
along
>with the data table.
>
>Additionally, there would be a few associated pointer / counter
>files that would at most take up another 1000 bytes.
>
>That's it: software of about 50KB capable of generating about
3E12
>random digits with data files of about 8KB all of which will run
>entirely in RAM (being loaded directly from floppy diskette).
Then
>when the encryption or decryption is completed, the only new
data
>written to the diskette would be the updated pointer / counter
>files.
So what? Peekboo 3 (still not released) is 75kb and it can use
public key algorithms (ie make/copy/paste/delete keys)
encrypt/sign/decrypt text messages and files using one of 8
different symmetric ciphers. It even has a prng too.
I could write a simple stream cipher in all of 4kb for win32,
big deal.
>I could incorporate a short routine in the encrypt / decrypt
software
>to overwrite RAM to provide about as good of computer hardware
>security imaginable or possible. Nothing from the diskette
goes to
>your hard drive and the RAM is overwritten. Very clean.
Except the swap memory. Oh well.
>Get an 800MHz or faster Pentium III or AMD Athlon CPU with full
>speed on board cache and I think encryption / decryption could
be
>done quite quickly and efficiently.
With a 800mhz Athlon my RC5 routines can encrypt at +50mb/sec is
that enough? Geez.. on my K6-2 400mhz I can encrypt at
24.2mb/sec which most likely beats your speeds anyways.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: PGP wipe how good is it versus hardware recovery of HD?
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 26 May 2000 03:31:56 -0700
In article <[EMAIL PROTECTED]>,
Lee Herfel <[EMAIL PROTECTED]> wrote:
>I have a program called shredder which I believes overwrites a
file 7
>times with random data to try and prevent hardware recovery of
deleted
>files aka the story in the WSJ. Does PGP wipe function do this
or does
>it only overwrite once?
Er, all you need todo is overwrite a file once to completely
kill the information.
Despite what others think, once you overwrite the information on
disk once or twice, it's completely gone. This is because the
hard disks are so dense there is no room for 'extra' noise.
The HD recovery attacks mainly would work on floppy disks since
each drive is not aligned the same (got this info from a
friend).
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: PGP wipe how good is it versus hardware recovery of HD?
Date: Fri, 26 May 2000 10:58:32 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In article <[EMAIL PROTECTED]>, Lee Herfel
<[EMAIL PROTECTED]> wrote:
>I have a program called shredder which I believes overwrites a file 7
>times with random data to try and prevent hardware recovery of deleted
>files aka the story in the WSJ. Does PGP wipe function do this or does
>it only overwrite once?
Whether PGP wipes at all, and whether it wipes more than once, appears to
depend on both your version of PGP and your operating system:
http://www.McCune.cc/PGPpage2.htm#Wiping
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.1
Comment: My PGP Page & FAQ: http://www.McCune.cc/PGP.htm
iQA/AwUBOS5Y6Q2jfaGYDC35EQKZ4wCg0CxmQRFXEaioYh4KybJJjOskFsgAoPpk
1JPF2zxvlbW5XPLpAvfSg+Bd
=5jtG
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 26 May 2000 13:28:28 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: MD5 win32 / linux compatibility
Matt Farnell wrote:
> Any help would be much appreciated. Here's the problem
>
> I'm using an MD5 c++ class to basically hash files. When using this MD5 code
> I get a certain output. I can get this same output by using someone else's
> win32 MD5 command line utility. Therefore this confirms that the result must
> be correct as two different sources resulted in the same 16 byte output.
>
> The problem I have is when I compile md5 source on linux I get another 16
> byte
> output which does not equal my hash result using windows. I am hashing the
> exact same file. I have also used two different linux MD5 sources that give
> the same result as each other although still different to the windows
> result. I have also compiled the linux source on both a MIP's and intel
> based system and the results are the same as each other although different
> to windows.
> Am I doing or not understanding something fundamentally obvious ?
You have 'md5sum' on many linux systems. Its output is 100% trustable
(you can check this by downloading software packages such as the
linux kernel, plus their md5 checksum). If your windows tools say
something different or those Linux sources say something different
they are buggy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Base Encryption: Revolutionary Cypher
Reply-To: [EMAIL PROTECTED]
Date: Fri, 26 May 2000 11:13:52 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> ...but you can't see a failure to get avalanche in *any* base and have
:> good overall diffusion properties. If your system exhibits good
:> avalanche properties, it should not be possible to transform it into
:> another base, and watch the avalanche disappear. If you can do this, the
:> system has undesirable cheracteristics in that base.
:>
:> This is the case Eric was describing. He wasn't seeing avalanche, and
:> erroneously concluding that therefore, the effect would happen in all
:> bases. He was seeing a /lack/ of avalanche - and concluding that the
:> system was broken.
: Pardon, I haven't yet fully understood you. The first paragraph seems
: to says that avalanche, if present in one base, should manifest in another.
: I guess that it logically follows that if avalanche is not observable
: at all in one base, then it shouldn't manifest in another. But this seems
: to contradict the content of the second paragraph.
You can probably observe avalanche in one base, and not in another -
though changing base usually affects diffusion /mainly/ in one direction.
I.e., if you change from base 10 to base 11, flip a low order digit, and
then convert back, the upper digits are likely to remain unchanged -
unless the lower digits happen to all be nines or all zeros.
However, if you do the same, and flip a more significant digit, the result
on the original digits after converting back will be more widespread
chaos.
If your cypher fails to exhibit avalanche when viewed from the perspective
of *any* base, that's a big problem for it.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
------------------------------
** 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
******************************
