Cryptography-Digest Digest #194, Volume #13 Mon, 20 Nov 00 20:13:01 EST
Contents:
Re: [Question] Generation of random keys ([EMAIL PROTECTED])
Re: More about big block ciphers (Tom St Denis)
MasterPass Puts Unrecoverable Master Password on MS Word Documents ("CMan")
Re: Cryptogram Newsletter is off the wall? (Shawn Willden)
Re: Proof of posession ([EMAIL PROTECTED])
Re: The Last On means 1st Off Rule (John Savard)
DES assistance, please? ([EMAIL PROTECTED])
Re: Cryptogram Newsletter is off the wall? (Shawn Willden)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: [Question] Generation of random keys
Date: Tue, 21 Nov 2000 00:06:24 GMT
In article <[EMAIL PROTECTED]>,
John Myre <[EMAIL PROTECTED]> wrote:
> This is truly bizarre. Do you actually think that a bias estimate
> derived from 100 flips is meaningful when attempting to obtain
> 160 bits of entropy?
Actually yes it is, because it will give an estimate of the bias of the
coin. I chose 100 because it easily converts to percent, and using that
percent you can determine the maximum number of flips to get 160-bits
of entropy. The additional 25% that I suggested was to compensate for
just such statistic problems as not having a large enough sample. It is
not an overly scientific process, and with knowledge of millions of
flips to analyze you can get a far better entropy estimate, and
consequently reduce the 25% done to (virually) non-existent, and even
base the number of flips on the past history.
My idea was very similar to yours, take a coin that just happens to be
in your pocket (I assume that it may be tampered with somehow), and
perform the analysis. Since I've performed a very coarse analysis of
this using US pennies (random sample of 36, years 1979-1986), and I
found that the pennies involved were biased up to 6% in either
direction, generally towards tails (overall 1% bias, on 500 flips per
coin). Based on this I'd say that to generate 160-bits of entropy a
safe number would be 170 flips. However because my sample was so small,
I encourage hedging my bets, and accepting some tampering, 200 flips
should be more than enough in almost all situations. Adding in extra
steps of analyzing the data, you can compensate for somewhat large
quantities of tampering, and you end up with something similar to my
(simplified) proposal. I was simply attempting to gaurentee the
generation of at least 160-bits of entropy (as opposed to very close to
160-bits of entropy).
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: More about big block ciphers
Date: Tue, 21 Nov 2000 00:10:17 GMT
In article <d1fS5.294$[EMAIL PROTECTED]>,
"Manuel Pancorbo" <[EMAIL PROTECTED]> wrote:
> **** Huge-block cipher BUTTERFLY ****
>
> In a previous thread I discussed with some of you about big-block
ciphers
> with a feedback stream engine. Now I present my own proposal that I
name
> "butterfly". See source code, testvectors, performance test programs
and so
> on in:
I already posted why your S0[S1[x xor k) <<< 4] is a bad mixing
function (when S0/S1 are parallel 8x8 substitutions).
If I misunderstood then I am sorry, but if you are not listening SHAME
ON YOU!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: MasterPass Puts Unrecoverable Master Password on MS Word Documents
Date: Mon, 20 Nov 2000 17:24:04 -0700
For Further Details see http://www.crak.com/masterpa.htm
MasterPass
Protects Against ALL Commercial Password Recovery Software!
(Uses An Abbreviated One Time Pad)
Download MasterPass - Demo Limited to Short 3- Character Passwords. If you
live in the USA or Canada send us E-Mail requesting the full version. You
must meet all applicable US laws to download this software - if you can
figure them out, that is...
If you are disgusted by the easy availability of commercial password
recovery software that allows users to recover passwords from Word
documents, then you need MasterPass. MasterPass plugs a security defect in
the encryption routines used by MS Word that allows recovery of the document
password.
Features:
* Adds a Supervisory or Master Password to Word Documents
* Prevents Password Recovery by Any Available Software - The Password is
Simply Not Recoverable!
* Allows Long Master Passwords or Passphrases for Extra Security
* Does Not Alter Word Encryption Algorithm, Key Length, or Strength
* Documents May Be Recovered by Special Key Search Software - This Process
Takes Several Weeks on The Fastest PC's Available Today
JK
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Mon, 20 Nov 2000 17:17:22 -0700
Tom St Denis wrote:
> In article <MqTR5.975$17.26756@stones>,
> "Brian Gladman" <[EMAIL PROTECTED]> wrote:
> > There is almost nothing to tie a digital signature to the person who is
>
> > alleged to have made it but it is really quite hard to forge an
> ordinary
> > signature
>
> Ok if digital signatures are so bad why not sign your original post
> with my public key off my website?
That's not the issue. Of *course* digital signatures can be practically
unforgeable, given all of the proper precautions; that's what they're
designed for.
In the real world, however, it's not so clear what the *legal* value of
digital sigatures is. Supposing the original post showed up with your
signature attached to it. Could a court of law then presume that you in
fact signed that document, based on the fact that the public key appears on
a web site that you purportedly own? Look at the other side of it.
Suppose that you wanted to show that you had _not_ signed the document;
what kinds of plausible explanations could you come up with as to how your
private key had been compromised? Or that that wasn't really your public
key? Or that you had meant to sign something else? Etcetera. Be
creative!
The problem isn't just eliminating non-repudiation, either. False
signatures are a problem as well. A trojan could be installed on your
computer which compromises your key. Or, if you use your smart card to
sign a document (making key disclosure effectively impossible), the trojan
could simply substitute its document when you sign something you wanted to
sign. Completely secure digital signatures require completely secure
signing platforms. Complete security is not possible in the real world, so
we have to settle for something less and then figure out how to deal with
the messiness.
IMO, however, none of this is an insurmountable problem. People can learn
to become comfortable with what they don't understand (I haven't understood
my automobile in detail for many years now) and society can work out ways
to deal with an imperfect system.
The *real* problem we have right now is that the current digital signature
laws on the books are too strong. Rather than making digital signatures
equal in force to a handwritten signature, the laws make them stronger.
Unlike handwritten signatures, digital signatures do not require the
signer's testimony to back them up in a court of law. I'm not clear what
would (will!) happen when someone goes to court and repudiates a signature
made by "their" private key. Is the burden of proof on them to show that
they are lousy at protecting their keys and/or system? Is that even
enough?
I think I do understand the point Bruce's article is trying to make.
Digital signature technology is fine; the precise legal meaning that can or
should be attached to a digital signature is much trickier, and probably
can only be defined in hindsight, after we slowly acquire real-world
experience. Bruce is definitely right to point out that with all the
layers of software involved it's much harder to consider a digital
signature a legal statement of intent, if for no other reason than the
average person can be certain what they're signing when they put ink to
paper. The analogous electronic situation (positioning a mouse over a
representation of a button near a representation of legal text internally
represented by a pile of bits, clicking the mouse, causing said pile of
bits [we hope!] to be run through a secure hash function and that result to
be raised to a large power which value is kept secret [we hope!] using a
large public modulus that has a particular mathematical relationship with
the secret exponent [we hope!] and which is known to be associated with a
particular person [we hope!]) is much less clear.
Shawn.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Proof of posession
Date: Tue, 21 Nov 2000 00:24:28 GMT
> (which need not be centralized, web-of-trust is fine) distribute a
> cryptographic signature for each file. Since the signatures are
probably
> a lot smaller than the files, users could afford to download a
database of
> signatures and then check files against them to verify that the files
are
> correct. But that delays the check until after the download, which
> isn't ideal. Ideally, someone who advertises a file would have some
way
> of proving that they have the file, before it's transmitted, and
someone
> who receives a file would be able to verify that it is the correct
file,
> during or before the download.
>
> Well, verifying that a file is correct can't really be done until
after
> it's all downloaded. We could improve things a little bit by having
the
> authority sign chunks of the file, and then the receiver can verify
each
> one as soon as it's downloaded before bothering to download the
rest.
> But that's limited by how big we're willing to make the signatures, an
> attacker could cause a whole lot of annoyance by giving out all the
> chunks except the last one, and it sure looks like it's the best we
can do.
I think you already see that this database of signatures is going to
get very costly to create/maintain. I think a better idea would be to
create a trusted tree of hashs, with the top one signed. This would
reduce the compute overhead and as long as you didn't maintain it as a
binary tree, but instead an n-tree you would gain size benefits as well.
>
> What about proof of posession? If the person advertising the file
can at
> least prove that they *have* the correct file, then even though they
might
> not really transmit that file when someone tries to download it, it at
> least forces them to maintain a copy of the correct file, and that
will
> filter out a lot of cheaters. It would seem that what we need here is
> some kind of signature or proof-of-identity scheme where the correct
file
> is an indispensible part of the secret key and the public key is short
> enough that users can conveniently store thousands of them.
>
> The simplest thing we could do would be to just hash the file, use the
> result as a seed for a random number generator, and then use that to
> generate a public/private key pair for some standard scheme. That
way,
> the person advertising the file can prove posession of the private
key,
> and that shows that they had the cooperation of someone who had the
file
> at some point in the past, in order to generate the key.
Unfortunately,
> it doesn't put a big burden on the attacker because they don't need to
> store the correct file - only its hash.
>
> Is there a way to prove posession of a *large* secret, with a *small*
> public key? I'm guessing that there may be a simple information
theoretic
> proof that this is impossible, but I'd be interested to hear anyone
else's
> thoughts on it.
Well since the target is slightly different than your last statement I
will supply an answer slightly differently. The protocol is amazingly
simple (and has a MITM attack so be careful):
Skeptic Client: What is the hash of the file prepended with X
Server->SC: H(X|file)
Skeptic Client: What is the normal hash value
Server->SC: H(file)
With this protocol a central trusted authority could retrieve the files
at various times, and query servers for the information. Since the TA
has a local copy the double hashs can be verified, and since the pre-
image hash cannot be computed until the pre-image is known, the server
MUST maintain a local copy of it to reply correctly. Then everyone
trusts central authorities and suggests when challenges should be made.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The Last On means 1st Off Rule
Date: Tue, 21 Nov 2000 00:27:15 GMT
On Mon, 20 Nov 2000 22:22:36 GMT, [EMAIL PROTECTED] wrote, in
part:
>Load into a
>2D array (with odd number of columns and rows -
>filling undef. with junk) and have a decimal PRNG
>move the columns down by 0 to 9 places, returning
>hex characters to the top of the column.
>Rotations are accumulative and can be added or
>removed in ant order.
That clearly can't be used for the Shamir three-pass protocol, for the
same reason Vigenere can't.
I send:
567891234
I recieve back
891234567
I send back
456789123
Comparing what I recieved back, and what I sent back, deciphering my
rotation involves putting the 1 where the 5 was, so applying that to
what I sent the first time reveals the message:
123456789
Of course, if the "scramble without a key" were secret...but then it
wouldn't be without a key, it would be the key.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: DES assistance, please?
Date: Tue, 21 Nov 2000 00:26:22 GMT
/*
To learn more about DES and encryption, and provide a valuable tool for
educators, I've implemented 16-round DES in Microsoft Excel using only
formulas (no VBA). With this spreadsheet, educators will have a tool
for better explaining exactly how DES works, and students can kick
around DES for themselves without coding in C. Also, it's going to be
a focus for a research paper for my Information Warfare class.
Right now, I have DES implemented in ECB mode, and hope to add CBC mode
and Triple-DES. (Also, Ceaser, Streaming Ceaser, and ADFGVX are done,
will add Vigenere soon.)
Unfortunately, my DES won't decrypt, so I don't know if I'm doing it
right, and don't have a way to independently generate DES to see if
it's my encryption or decryption that's broke. I've spent about 20
hours on it now, and can't find the bug. Assistance please oh please?
*/
__________
THE POINT:
==========
Would someone please volunteer to encrypt the same text with the same
key, and let me know what results you get?
OR: If any of you have a DES executable that provides the output at
each round, this would accomplish the same thing, and I could run it.
I'll post the spreadsheet to this forum once it's done, and share with
all.
My results are below.
Daniel D. Houser, CISSP, SSCP
Sr. Security Engineer
[EMAIL PROTECTED]
================================================
16-Round DES, ECB mode (not that it matters with 8 bytes!)
Key: "abcdefgh"
Cleartext: "butterfl" (please ignore the quotes)
Ciphertext: 60 FF B8 2B 2F 53 2E F0
Keys given after appropriate shift for round, prior to the key
compression permutation. Ciphertext given after each round, post
left and right shift, which is (of course) the input to the following
round.
Text After Initial Permutation:
0110001001110101011101000111010001100101011100100110011001101100
Round 1 Key:
00000001111111111111111000001100110011110001000000000000
Round 1 Output:
1110000010100101010100011100111110000010110100000010010110111011
Round 2 Key:
00000011111111111111110000001001100111100010000000000001
Round 2 Output:
1000010000100001001101101001110001100100100001000110011101010011
Round 3 Key:
00001111111111111111000000000110011110001000000000000110
Round 3 Output:
0010110110111010101110001000010110101001100110111000111000011001
Round 4 Key:
00111111111111111100000000001001111000100000000000011001
Round 4 Output:
1111010111101001011000101101011111011000010100111101101001010010
Round 5 Key:
11111111111111110000000000000111100010000000000001100110
Round 5 Output:
0111110010101110111000110110001010001001010001111000000110110101
Round 6 Key:
11111111111111000000000000111110001000000000000110011001
Round 6 Output:
0001011110100001010001011110101101101011000011111010011010001001
Round 7 Key:
11111111111100000000000011111000100000000000011001100111
Round 7 Output:
1010101111111010000010000010000010111100010110110100110111001011
Round 8 Key:
11111111110000000000001111110010000000000001100110011110
Round 8 Output:
0011111110111110101011101100011110010100010001001010011011100111
Round 9 Key:
11111111100000000000011111110100000000000011001100111100
Round 9 Output:
1011011000100001011001100011111010001001100111111100100011111001
Round 10 Key:
11111110000000000001111111110000000000001100110011110001
Round 10 Output:
0100011001101111101110100000001111110000010011101101110000111101
Round 11 Key:
11111000000000000111111111110000000000110011001111000100
Round 11 Output:
1111100010010001011000111011000110111110111111101101100110110010
Round 12 Key:
11100000000000011111111111110000000011001100111100010000
Round 12 Output:
1101000000101010000000011011000100101000101110110110001000000000
Round 13 Key:
10000000000001111111111111110000001100110011110001000000
Round 13 Output:
0110110010010111000100111110001110111100101111010001001001010010
Round 14 Key:
00000000000111111111111111100000110011001111000100000000
Round 14 Output:
0111100010010000100010010101100100010100000001111001101010111010
Round 15 Key:
00000000011111111111111110000011001100111100010000000000
Round 15 Output:
0010010101111001000011000100000001011101111010011000010100011001
Round 16 Key:
00000000111111111111111100000110011001111000100000000000
Round 16 Output:
1010001110100110010100100011101010000110110111110101111001111010
After final permutation:
0110000011111111101110000010101100101111010100110010111011110000
60 FF B8 2B 2F 53 2E F0
ddh
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Mon, 20 Nov 2000 17:47:21 -0700
wtshaw wrote:
> In article <[EMAIL PROTECTED]>, Bruce Schneier
> <[EMAIL PROTECTED]> wrote:
> > The job of the good
> > security engineer is to imagine how things could not work properly,
> > and to prepare for those eventualities.
> >
> > Bruce
>
> The security of the vessel
> is in preventing/containing and in outpumping any leak, both of which
> techniques are seen in trying to maintain electronic security. Good
> design fights the battle in structure first rather than looking for
> whimsical dynamic action.
Nice analogy. Every seaworthy boat has both a good hull *and* bilge pumps.
Shawn.
------------------------------
** 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
******************************
