Cryptography-Digest Digest #548, Volume #13 Thu, 25 Jan 01 12:13:00 EST
Contents:
Re: Knots, knots, and more knots (Richard Heathfield)
Re: DES check values ("madcow")
Steak Stream Cipher ([EMAIL PROTECTED])
Re: How much of this group's discussion violates the DMCA (Dido Sevilla)
Re: Random stream testing. (long) ("Gary Watson")
Re: "How do we know an Algorithm is Secure?" (was RC4 Security) (DJohn37050)
Re: How many bits of security can a password give? (rot26)
Re: Fitting Dynamic Transposition into a Binary World (John Savard)
Windows encryption: API and file system ("Ben Newman")
Re: Creating a self extracting encrypted exe? (Kent Briggs)
Re: How many bits of security can a password give? (Erik Runeson)
Re: How much of this group's discussion violates the DMCA (Jerry Coffin)
Re: Windows encryption: API and file system (Bryan Mongeau)
Re: Barrett modular reduction ([EMAIL PROTECTED])
----------------------------------------------------------------------------
Date: Thu, 25 Jan 2001 14:05:18 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Knots, knots, and more knots
Matthew Montchalin wrote:
>
> On Wed, 24 Jan 2001, Matthew Montchalin wrote:
>
> |Imagine you have this very long rope, and you've got this machine
> |with two holes, where you feed the rope completely through the
> |machine, and before it comes out, it will either be knotted, or
> |unknotted, depending on the state of a punch-card (ahem) that has
> |been inserted into the machine in advance. Let us further assume
> |that the machine does not stretch the rope longer than it was
> |to start with, and does not shorten it in any way.
> |
> |Starting with this simple setup, is it reasonable to describe
> |complexity by the knots per unit length of rope, multiplied by
> |the operations specified on the punch card?
(Clearly, we can describe the rope's knots as 0 = no knot, 1 = one knot,
so it's just a way to represent binary.)
I must have misunderstood what you meant because, the way I figure it,
this scheme would give maximum complexity (for a given, non-zero, series
of operations on the punch card) to 11111111 and minimum complexity to
00000000, whereas it seems to me that neither of these bitstreams is
more complex than the other - they are separated only by a single NOT
instruction.
Also, I'd argue that 10100111 is more complex than either of them.
Consider the descriptions in English:
Eight ones.
Eight zeros.
A couple of one-zero pairs, then a zero, then three ones.
Surely the last one is more complex?
Of course, you might find simpler descriptions for each of them... e.g.
FF, 00, A7. Now count the number of different symbols required to
describe each...
So the knots don't seem to tie it up completely, do they? In fact, it's
a bit of a tangle. Defining complexity is a knotty problem indeed.
--
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: "madcow" <[EMAIL PROTECTED]>
Subject: Re: DES check values
Date: Thu, 25 Jan 2001 08:54:29 -0500
You can get source code for DES in Basic at :
http://home.wxs.nl/~napel/des.htm
58 <[EMAIL PROTECTED]> wrote in message
news:94n7hb$ij0$[EMAIL PROTECTED]...
> My company uses DES to encrypt fixed length (16-character) values.
> Much as I'd like to see them make the leap from DES, it's what our
> system, indeed all the businesses with which we work, uses.
>
> I am a custodian for one part of the clear text, and I am a hobbyist
> BASIC programmer (no laughing, please). One business to whom we must
> occasionally send this text requires that we apply some simple XOR math
> to mask the true text. This isn't hard, and I've written a program
> that does this for us and fills out a form.
>
> The business also asks that we provide a check value for the clear
> text, so that they can confirm it when they undo the XOR functions.
> And this is where I'm not proceeding well. For my tests, I used our
> Atalla SIU to generate some random clear text and the check values for
> each. When I try to generate my own check values, they're wrong.
>
> I understand that the algorithm to generate a check value simply
> encrypts with a key of all zeroes. I confirmed this on our SIU. I
> followed the ANSI standard to the best of my knowledge, making sure
> each step of the algorithm had its own routine, and the routines and
> tables all look right. The minor adjustments I've made don't change
> the check value, and I'm not sure where the real problem is (should be
> beyond the last sections, but I've adjusted those, too).
>
> So, I guess the easiest step, vice trying to re-invent this wheel, is
> to determine if such a program already exists. It doesn't have to be
> BASIC, but it does need to run on an NT. If the program accepted input
> on the command line, so much the better so I could integrate it with
> the bits I've already written.
>
> If anyone knows of such a beastie I would appreciate hearing about it.
> I would prefer a followup here, but email is also acceptable.
>
> Thanks,
> Larry
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Steak Stream Cipher
Date: Thu, 25 Jan 2001 14:04:09 GMT
My company has decided to publish the source code
and a brief documentation of our most recent
crypto project - a two way error propagating
stream cipher we pretentiously call Steak
(because it is both rare and well-done).
the url is http://www.streamsec.com/steak.asp
We would very much appreciate comments,
questions, suggestions etc of any kind. We have
been testing the Cipher for some months know, and
are not done yet. We plan (and hope) to implement
a final version of this cipher in a secure ftp
derivate client/server solution later on this
spring.
Henrick Hellström
StreamSec HB
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: How much of this group's discussion violates the DMCA
Date: Thu, 25 Jan 2001 22:04:43 +0800
Richard Heathfield wrote:
>
> "David C. Barber" wrote:
> >
> > I wonder how much of this group's current discussions about systems and how
> > they're broken is in violation of the Digital Millennium Copyright Act,
> > which prohibits any attempt to reveal or break even lame systems.
> >
> > Any informed opinion(s) on this?
>
> No, just a question.
>
> In which country is that law applicable?
>
Sadly, the law's reach definitely exceeds its grasp, else wherefore Jon
Johansen? US law is gaining the annoying ability to affect nations
where such laws should, in theory, posess no force. The United States
is well known for interfering in the affairs of other nations, but while
in the past it had been the federal government doing it with the threat
of nukes and warplanes, now, it is US corporations doing it with money
to make the GNP's of some smaller nations look like drops in a bucket...
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: "Gary Watson" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Random stream testing. (long)
Date: Thu, 25 Jan 2001 13:36:18 -0000
"Paul Pires" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In learning about testing PRNG's and RNG's I have
> run into a confusion. How it "must be" is different from
> how it is discussed. Perhaps I misunderstand.
>
> Note:
> Throughout this discussion the usefulness of random
> testing will be questioned. Obviously, it is useful in
> eliminating putrid concepts. The focus here is on how
> this endeavor can be improved to quantify differences
> between "Good & Practical" sources.
There's a good introduction to randomness testing on the NIST web site at
http://csrc.nist.gov/rng/
I think you should read their report on the AES candidates to see how they
use their tools in practice.
--
Gary Watson
[EMAIL PROTECTED] (you should leave off the digit two for email)
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 25 Jan 2001 14:35:41 GMT
Subject: Re: "How do we know an Algorithm is Secure?" (was RC4 Security)
Mr. Murray's comments are right on.
Don Johnson
------------------------------
From: rot26 <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Thu, 25 Jan 2001 14:32:24 GMT
You might find this helpful:
http://www.cl.cam.ac.uk/ftp/users/rja14/tr500.pdf
rot26
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Fitting Dynamic Transposition into a Binary World
Date: Thu, 25 Jan 2001 15:16:28 GMT
On Thu, 25 Jan 2001 06:23:15 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>Since the description in my "Revisited" article is not working, and
>since -- for some reason -- I am obviously not getting through,
>perhaps someone else could help out here.
Given your description:
:Some of the analytic and strength advantages of Dynamic
:Transposition depend upon having the same number of 1's
:and 0's in each block, which is called "bit-balance."
:Exact bit-balance can be achieved by accumulating data to
:a block byte-by-byte, only as long as the block can be
:balanced by adding appropriate bits at the end. Then the
:block is ciphered, and another block filled.
:We will always add at least one byte of "balance data,"
:at the end of a block, and only the first balance byte,
:immediately after the data, will contain both 1's and 0's.
:We can thus transparently remove the balance data by
:stepping from the end of the block, past the first byte
:containing both 1's and 0's.
and also
: It does bit-balance arbitrary data into a
: fixed-size block, is not limited in block size (and thus gains
: efficiency with large blocks), and decoding is trivial.
I thought that I accurately described your algorithm, although I
worked backwards rather than forwards in determining when to complete
a block, and I explicitly noted one pathological case.
A block balanced by your algorithm will always consist of one byte of
balancing data containing both 1s and 0s, followed by zero or more
bytes of balancing data containing only 1s or only 0s.
Thus, an N byte block can be balanced, when containing N-k bytes of
input data, if the excess of 1s or 0s in the input data is less than
or equal to 7 + 8*(k-1); that is, N-1 bytes can be balanced with an
excess of 7 1s or 7 0s or anything in between, N-2 bytes can be
balanced with an excess of 15 1s or 15 0s or anything in between. Or
can they?
It might happen that I have N-2 bytes of balanced data followed by one
byte of all 1s. Let's say that each of the first N-2 bytes has 4 1
bits and 4 0 bits, so that the first N-2 bytes are perfectly balanced
no matter where I truncate them, for simplicity in what follows.
If I try to balance that by your algorithm, I find I have eight excess
1s, so I can't put N-1 bytes of data in my N byte block.
How about N-2? Now, my data is *too* balanced. My first balancing byte
cannot be all 1s or all 0s, or it won't decode. But my second
balancing byte must be all 1s or all 0s. So those two bytes together
can't balance!
So I have to balance the block by putting in N-3 bytes of balanced
bits, followed by one byte with 4 0s and 4 1s, followed by an
all-zeroes byte and an all-ones byte (in either order).
Thus, although your description of your algorithm didn't include
backtracking, there is in fact a slight need for it.
A modification of your algorithm, making the single balancing byte of
the form 01111111, 00111111, ... 00000001, and using the bit pattern
11110000 *along with* 00000000 and 11111111 as an allowed value for
the second and subsequent balancing bytes, would eliminate this
complexity.
I also note that your original Dynamic Transposition article is from
1991, so it may well be the first proposal ever openly made for any
form of polyalphabetic block encipherment. Thus, even if my claim that
one can avoid the overhead of bit-balancing by doing something just as
good with substitution is true, that has less impact on the
significance of Dynamic Transposition than I had thought.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Ben Newman" <[EMAIL PROTECTED]>
Subject: Windows encryption: API and file system
Date: Thu, 25 Jan 2001 15:37:17 GMT
I'd like to learn more about criticisms of the Windows cryptography
implementation. In response to an earlier post, someone characterized it as
"practically useless." This seems like a particularly important issue given
the amount of knowledge your average Windows user has about crypto.
--ben
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Creating a self extracting encrypted exe?
Date: Thu, 25 Jan 2001 15:42:31 GMT
Paul Pires wrote:
> My apologies for: A, miss-spelling your name and
> B, for poorly writing my own post. In re-reading it,
> now it sounds like I'm calling you a snake oil peddler.
No problem, I knew you weren't referring to me. I just took advantage of your
post to plug my program. :-)
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: Erik Runeson <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Thu, 25 Jan 2001 15:48:45 GMT
In article <94pddq$dlc$[EMAIL PROTECTED]>,
rot26 <[EMAIL PROTECTED]> wrote:
> You might find this helpful:
>
> http://www.cl.cam.ac.uk/ftp/users/rja14/tr500.pdf
Thanks! Just what I needed.
---
Disclaimer: This post represent my personal views,
not those of my employer.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: How much of this group's discussion violates the DMCA
Date: Thu, 25 Jan 2001 09:34:09 -0700
In article <94n560$e98$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> I wonder how much of this group's current discussions about systems and how
> they're broken is in violation of the Digital Millennium Copyright Act,
> which prohibits any attempt to reveal or break even lame systems.
>
> Any informed opinion(s) on this?
If so, it would simply show that the DMCA is unconstitutional. It's
_very_ clear that what takes place here is discussion, not action.
As such, it is protected as free speech. It's barely possible that
based on the discussions here somebody to take an action that
violated the DMCA and might not, itself, be protected as free speech,
but that's an entirely separate question from the discussion itself
being a violation.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: Bryan Mongeau <[EMAIL PROTECTED]>
Subject: Re: Windows encryption: API and file system
Date: Thu, 25 Jan 2001 16:56:21 GMT
Ben Newman wrote:
> I'd like to learn more about criticisms of the Windows cryptography
> implementation. In response to an earlier post, someone characterized it
> as "practically useless." This seems like a particularly important issue
> given the amount of knowledge your average Windows user has about crypto.
>
> --ben
>
>
I don't know if this what you mean but I saw this on Bugtraq
a few days ago:
==============================================
BugTraq: EFS Win 2000 flaw
From: Rickard Berglind <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Fri, 19 Jan 2001 12:29:50 +0100
I have found a major problem with the encrypted filesystem
( EFS ) in Windows 2000 which shows that encrypted files
are still very available for a thief or attacker.
The problem comes from how EFS works when the encryption
is done. When a user marks a file for encryption a
backup-file, called efs0.tmp, will be created. When
the copy is in place the orginal file will be deleted
and then recreated, now encrypted, from the efs0.tmp-
file.
And finally, when the new encrypted file is succesfully
created, the temporary-file ( which will never be shown
in the user interface ) will be deleted as well.
So far, so good. The only file remaining is the one
which is encrypted.
But the flaw is this: the temporary-file is deleted
in the same way any other file is "deleted" - i.e.
the entry in the $mft is marked as empty and the clusters
where the file was stored will be marked in the $Bitmap
as available, but the psysical file and the information it
contains will NOT be deleted. The information in the
file which the user have encrypted will be left in the backup
file efs0.tmp in total plaintext on the surface of the disk.
When new files are added to the partition will they
gradually overwrite the secret information, but if
the encrypted file was large - the information could
be left for months.
So how can this be exploited ? If someone steals
a laptop or have psysical access to the disk it will
be easy to use any low level disk editor to search
for the information. For example, the Microsoft
Support Tool "dskprobe.exe" works fine for locating
old efs0.tmp-files and read information, in plain-text,
that the user thought was safe.
In my opinion there should be a function in the EFS
which physically overwrites the efs0.tmp at least once
to make it a lot harder for an attacker to gain control
over secret information.
Here is a description how to test this :
Use any version of Windows 2000.
Install the Support Tools from the Win2000 CD.
For demonstrating purposes - create a new partition with
the size of 7 MB.
Choose to format with NTFS.
Create a new small file ( easier to find ) with Notepad
and put some text in it. Save this file in the root of the
new partition.
Do not encrypt it yet.
Let us look at the file through DiskProbe before encryption-
start Diskprobe from Support Tools on the Start Menu.
A. Choose the "Drives"-menu and "Physical Drive"
Double click on "physical drive 0" ( or other drive you are using )
Click "Set active" and then "OK"
B. Choose "Drives" again and this time "Logical Volume"
Double click the drive letter for your new partition
and then "Set active" and "OK"
C. Choose the "Sectors"-menu and "Read". For starting number
type 80 and for the number - 35 perpaps.
Maximize the window and click the arrow for "Next sector".
At sector 86 you should see the name and contents of your
file ( assuming you made a new partition )
The file is obiously in plain text and easy to read for anyone
with physical access to this disk, regardless of permissions
in the ACL, which is ignored when using this kind of utiliy.
Better encrypt this file .. !
Now close the DiskProbe utility and open Explorer and locate
your new file. Choose Properties - Advanced - Encrypted - OK.
The file is now encrypted.
Wait a few moments to be sure the new data has been written
to the disk.
Open Diskprobe again and repeat steps A, B and C.
When reaching sector 86 you should be able to see the name
of your file, but not be able to read the information - it
is now encrypted.
But.. continue to click the Next Sector-Arrow and look carefully
at the information being displayed. A few sectors away from the
orginal file there should be a file called efs0.tmp - which is
the backup file EFS creats during encryption. You should ALSO
be able to see the contents of this efs0.tmp file - which will
be the data from the file you encrypted. The problem is just that
the data is in clear and plain text.
So again - anyone with physical access to this disk can read
the data you thought was safe.
/ Rickard Berglind
=================================================
--
<==================================>
Bryan Mongeau
Lead Developer, Director
eEvolved Real-Time Technologies Inc.
www.eevolved.com
<==================================>
"The fear of death is the most unjustified of all fears, for there's no
risk of accident for someone who's dead."-- Einstein
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Barrett modular reduction
Date: Thu, 25 Jan 2001 16:50:36 GMT
In article <94orld$vuu$[EMAIL PROTECTED]>,
Bryan Olson <[EMAIL PROTECTED]> wrote:
> Hmmm, I think it's straightforward, but can you tell why
> you need this? Working modulo n shouldn't require repeated
> calculations with anything more than twice the length of n.
>
Thanks for the explanation.
In RSA there's an alternate decryption using CRT; in place of c ^ d %
n, one can do
A (c ^ d % p) + B (c ^ d % q) % n
where
A=q * (q ^ -1 % p)
and
B=p * (p ^ -1 % q)
In this case c is of the same magnitude as n (ie 2x p's magnitude). In
the first round of finding modexp, this is squared, mod p, so you get
4x p's magnitude.
Is there a trick, like x %= m before the first round to prevent this?
This use of A and B is to accelerate the decryption, because A and B
can be precomputed, and the exponentiations % p and % q should be
faster than % n.
However, now that I have extended Barrett's reduction, I find that for
me c^d%n is slightly faster than the method with A and B. I expect
that's because I end up doing roughly the same number of reductions
either way. The speed difference is because of the higher overhead of
the A + B method.
Now I know.
john
Sent via Deja.com
http://www.deja.com/
------------------------------
** 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
******************************
