Cryptography-Digest Digest #35, Volume #9 Thu, 4 Feb 99 19:13:04 EST
Contents:
Re: Metaphysics Of Randomness (Medical Electronics Lab)
Re: David _R._ Scott ([EMAIL PROTECTED])
Re: DFC in 416 cycles/block on a Pentium Pro (Terje Mathisen)
The Hunt is On @ PAWS! (Richard Goldman)
_____FAQ list for this newsgroup_____ 978
([EMAIL PROTECTED])
Re: Foiling 56-bit export limitations: example with 70-bit DES ([EMAIL PROTECTED])
Re: Metaphysics Of Randomness (R. Knauer)
Re: Crypt Info ???? (Albert P. Belle Isle)
Re: Cracking 128bit (Albert P. Belle Isle)
Re: Loony question (Jim Dunnett)
----------------------------------------------------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Date: Wed, 03 Feb 1999 12:15:13 -0600
R. Knauer wrote:
> +++++
> A TRNG must be capable of generating all possible sequences of a given
> finite length equiprobably.
> +++++
>
> Here equiprobability means that the probability for generating any
> string of a given finite length is the same for any other string of
> the same length. Note that equiprobability applies to the generator
> and not any of the actual strings produced by the TRNG.
How about this instead:
+++++
A TRNG must generate all possible sequences of *any* finite length
equiprobably.
+++++
By equiprobably I mean "of equal probability", which I can measure
with statistics. Further, I can use statistics to tell me what the
variance is for any finite length smaller than the length of the
sample. If the variance is larger than the square root of the
number of elements, I probably have a problem (note, I'm not *sure*
I have a problem, and doing lots of statistics will help me
determine how much I need to worry about some stats test being
"out of bounds").
For most practical tests, the finite length is limited to 32 or fewer
bits. You can certainly do tests on larger bit lengths, but it
takes a *lot* more data. But you can't know what you're TRNG is
doing if you don't do statistical testing.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: David _R._ Scott
Date: Thu, 04 Feb 1999 21:52:56 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] () wrote:
> [EMAIL PROTECTED] wrote:
> : you greatly edited my response I assumed better of you.
>
> I didn't cancel your original post; whatever I didn't repeat is still
> there to be seen.
>
> I edited out your next two sentences here. I didn't feel I could reply to
> them in an adequate fashion.
I guess I can understand since you have not improved your
ability to focus any clearer than when you use to comment
in "The Gateway" or do I have you confused with a higher
quality person?
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: DFC in 416 cycles/block on a Pentium Pro
Date: Thu, 04 Feb 1999 22:14:44 +0100
Serge Vaudenay wrote:
>
> Dominik Behr and Robert Harley's new optimized asm Pentium Pro
> implementation of DFC is now encrypting within 416 cycles per
> block (without any API overhead), which makes it a fast
> decorrelated cipher, even on a Pentium.
Actually, that number is already old, our new value is 387 clock cycles
(PentiumII) for the inner core encryption code. :-)
BTW, credit should also be extended to Danjel McGougan, as he was the
one who put together and timed that particular version, with some input
from me.
Terje
PS. If timing attacks is a potential risk, our implementation can be
totally branchless and data-independent at a cost of 5 cycles/round.
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: Richard Goldman <[EMAIL PROTECTED]>
Subject: The Hunt is On @ PAWS!
Date: Thu, 04 Feb 1999 09:37:02 -0800
Reply-To: [EMAIL PROTECTED]
The Barbary Coast Armchair Scavenger Hunt and Trivia Contest is on at
PAWS. It takes place on Sunday, March 14th, 1999 on the internet from
your home from 12 til 4pm. Challenges are published on The Hunt website,
http://www.unexpected.com every 30 minutes for four hours. Your team
compete with other teams by solving these obscure brain teasers and
challenges to win fabulous prizes while raising money for Pets Are
Support. Registration is $15.00 per person with no maximum number of
participants per team, 100% of all registration fees goes directly to
PAWS. The more people on your team, the more likely you will be to
answer challenges correctly and win fabulous prizes. Check out The Hunt
website at http://www.unexpected.com for sample challenges and lists
of prize donors. Register your team early online or at (415)-863-3506,
as this event will fill up quickly. Remember the more people that
register on a team, the more money you can raise for PAWS and have a
good time doing it!
------------------------------
From: [EMAIL PROTECTED]
Subject: _____FAQ list for this newsgroup_____ 978
Date: 4 Feb 1999 22:08:31 GMT
http://news-faqlist.696.net
hgmmqirqdfnzospylcwpkxmrxjlzjuzbjbxodxczjwlngydurcwsuhpmtskzujpijidrsihithkdxjivohmgjlpxczvwtpmwuovmmllwwuglrwngrcmtciudjqmiijzwfcvqlgxtfwqenkxdoxrybtkfebdylp
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Thu, 04 Feb 1999 20:22:01 GMT
In article <79a19p$n3t$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
[snip]
> The reasons why adding a previous encryption to the plaintext are, mainly:
>
> 1. you are wasting controlled-bits if the previous encryption uses
> secret-bits. Mind you, this is important not only for those that live under
> such constraints but also to decrease secret-key sizes (smart-cards, etc).
I don't follow you. In your scheme, you have generated M bits and used them
to select an "unkown key." It doesn't cost much to apply the same unknown
key to both the plaintext and the DES ciphertext. See DESX.
> 2. if the encryption uses a second unknown-key then you are increasing the
> recipient's burden to obtain that unknown-key in the same amount as the
> attacker's, irrespective of DES,
I did not suggest that you use a 2nd unknown key.
> 3. you are working only in plaintext recognition, where the most effective
> attackers (NSA, for example) excel.
The purpose of pre-encrypting, in addition to post-encrypting, is to make the
post encryption more secure, in the event that the same message is sent twice
with the same DES key. I thought I made that clear.
> That is mainly why I said that if the plaintext is encrypted with an
> unknown-key (the choice I am considering) then the intended recipient will
> gain less in comparison to the attacker. I hope it si clearer.
It's not, really.
> > [snip]
> > > 1. That is not what WA says -- it is the amount of secret-key that is
> > > controlled. And, M-DES only defines a secret-key that is 56-bit wide
Please
> > > read the WA.
> >
> > I think I was clear that I was describing US export law.
>
> Still, ditto as I wrote. The M-DES method complies to the published US
> regulations -- and shows how impossible it is to try to control
> cipher-strength just by controlling bit-lengths. It further shows that you
> can't really ban secure ciphers because you cannot control what the other
> side ignores but may find much sooner than the attacker -- the unknown-key.
You are mistaken about U.S. export law. You've never worked to get export
approval for any real product, have you?
> >If you really want
> > your 56-bit algorithm to be strong,
>
> It is really negatively surprising to see you mention "If you really want
> your 56-bit algorithm to be strong, " when the algorith is 70-bit strong and
> NOTHING that you or anyone else have said so far has decreased the proposal's
> security! So, your phrase is empty. What is your objective, to pass through
> with a previoulsy denied qualification? BZZT!
Hey, don't get hostile. My intention was to provide useful feedback. If you
weren't interested in such, why post to sci.crypt?
> For a productive discussion, please first acknowledge what has been
> established -- not invent what has even been denied. The presented M-DES
> cipher is secure for 70-bits and so I have proven publicly -- you cannot name
> one weakeness (of course, if you follow what is in the paper). And, the paper
> discusses how it can be secure to 120-bits or even more. These are the points
> in discussion.
I can name a weakness. The post-encryption is much easier to break if the
same message is sent twice with the same DES key. I've also posted 2
remedies: a) do the post-encryption with a well-known block-cipher that will
accept M-bit keys, or b) apply the same "unknown key" to both the plaintext
and the DES ciphertext.
> And, mind you, with one 56-bit DES encryption per block. Not three.
It's true that the scheme I proposed takes Alice on the order of 4 times as
long to decrypt as the scheme you proposed. It's also true that my proposal
makes a cracker take 4*B times as long to break as your proposal, where B is
the total number of blocks in the ciphertext message.
--
Peter
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Thu, 04 Feb 1999 23:00:34 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 03 Feb 1999 12:15:13 -0600, Medical Electronics Lab
<[EMAIL PROTECTED]> wrote:
>How about this instead:
>+++++
>A TRNG must generate all possible sequences of *any* finite length
>equiprobably.
>+++++
You cannot require the TRNG to generate the sequences, only be capable
of generating the sequences. Some sequences that are possible may
never be generated in a million years.
In fast, forcing the TRNG to actually generate all possible sequneces
destroys its indeterminate nature. The whole point behind the TRNG
which gives it its proveably security is that no one can ever know how
it is actually going to behave.
>By equiprobably I mean "of equal probability", which I can measure
>with statistics.
Yes, but only th the level of proveable security if you do an infinite
number of measurements.
Further, I can use statistics to tell me what the
>variance is for any finite length smaller than the length of the
>sample. If the variance is larger than the square root of the
>number of elements, I probably have a problem (note, I'm not *sure*
>I have a problem, and doing lots of statistics will help me
>determine how much I need to worry about some stats test being
>"out of bounds").
You are using the binomial theorem in conjunction with the law of
large numbers to get a gaussian distribution which gives you that
sqrt(n) behavior. That tells you nothing about the behavior of a TRNG
in terms of proveable crypto-grade security. All it tells you is that
the bias is distributed binomially. The bias of any string generated
by a TRNG can be from one end of the sepctrum to the other, for finite
sets of strings. Only for an infinite set of strings can you say that
bias is not associated with randomness.
>For most practical tests, the finite length is limited to 32 or fewer
>bits. You can certainly do tests on larger bit lengths, but it
>takes a *lot* more data. But you can't know what you're TRNG is
>doing if you don't do statistical testing.
You know what your TRNG is doing because it is designed to tell you
about itself at ever stage of its subsystems. I posted extensive
comments on this earlier and do not care to bore readers with a
rehash. But in a nutshell, you can test any determinite characteristic
of the TRNGs subsystems, but not the final output
Since the final output must be completely indeterminant, there is no
testing possible for crypto-grade randomness. If you could test the
finite strings being output in finite number to learn something about
it, then they are not indeterminant.
Bob Knauer
"Sometimes it is said that man cannot be trusted with the government
of himself. Can he, then, be trusted with the government of others?"
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (Albert P. Belle Isle)
Subject: Re: Crypt Info ????
Date: Tue, 02 Feb 1999 16:36:34 GMT
Reply-To: [EMAIL PROTECTED]
On 2 Feb 1999 00:23:06 GMT, [EMAIL PROTECTED] (Jekman321) wrote:
>I'm hoping a few people can help me and give me some insight into the skilled
>specialty of encryption.
>
>I'm in the computer field myself but am the 1st to admit that encryption is not
>my forte and therefore know enough to inquire of the specialists in this field.
>
>I am interested in some encryption software out their that I can be comfortable
>with. I have absolutely nothing to hide on my pc, but if I have a love poem to
>my wife stashed on the HD, I feel that it is none of "Big Brothers" business
>(or anyone else's for that matter).
>
>I understand that current US regs prevent any software over 56-bit algorithm
>(?) from being shipped overseas.
>There are some exceptions. I am wondering if any encryption software out there
>over 90-bit is subjected to any laws within the US.
>
While certain people in some Law Enforcement Organizations (LEOs) have
promoted the establishment of federal laws restricting the use of
strong encryption by "US persons," the blatant unconstitutionality of
such laws have (so far) prevented their passage.
>I have looked into a Swiss company (www.sls.net) that boasts a program with a
>168-bit encryption algorithm. What I am wondering, is that, do these companies
>have to provide the Commerce Dept. with a key of any sort so that Uncle Sammy
>would have the capabilities to crack the code..?? From the looks of their
>program (DataGuard), I believe it might be worthwhile investment. Can anyone
>give some insight..??
>
Your mention of a 168-bit keysize would seem to imply that the cipher
used is 3-key triple-DES (the TDEA cipher from the proposed FIPS PUB
46-3 revision, after its adoption by the banking industry).
There is no a priori reason to assume that the US Commerce Dept (or
more appropriately the NSA's COMINT people or their FBI customers)
would have any more leverage with a non-US company than they would
with a US company.
The widely-rumored cooperation of the Swiss-based reincarnation of
Boris Hagelin's firm (Crypto AG) with NSA (through Germany's BND) has
not helped their commecial prospects very much, and wouldn't recommend
itself as a business strategy to any business manager alert to the
hazard of shareholder lawsuits.
Such "voluntary cooperation with the authorities" is not all that
probable, but certainly not impossible in return for "regulatory
relief." There is, however, no legal basis for requiring such
"features" in software sold in the US, wherever it comes from.
>While doing a small amount of research, I came across a company who mentioned
>or boasted that their software is not susceptible to "Forensic Software"
>attacks. My question is....Can someone give me the "short" version of what
>"forensic" attacks are..??
>
If you found the Cerberus Systems web-site, I may not be the best
person to (re-)explain material that apparently wasn't clear enough
the first time around. Nevertheless......
"Forensic software" is a term-of-art used by "computer crime
specialists" and others who sell such software and/or "data recovery"
services to LEOs, to lawyers pursuing "electronic discovery" of
evidence that supports their clients in a law suit, or to people and
organizations engaged in industrial espionage.
Basically, most commercially available versions combine direct
sector-level access to disk data (like sector-editing disk utilities)
with utilities for keyword- or filetype-searching, and with secure
database management functions to maintain an "evidentiary custody
trail" that can withstand court challenges by defense attorneys. ("The
prosecution must have made-it-up, your honor, it didn't come from my
client's computer.")
It exploits the fact that many Windows programs (and the operating
system itself) scatter copies of plaintext, keys and passphrases
around on your hard disk whenever you decrypt, edit or print-out
copies of sensitive data, so it can be "recovered" from these
fragments rather than having to crack the re-encrypted versions.
This is completely separate from the issue of strength of the ciphers
used by the encryption program itself, since the encryption is
bypassed.
>Can Uncle Sammy & the SS obtain my "key" with a "key" retrieval program..?? Is
>there anything out there to just prevent OLE Uncle Sammy from sticking his nose
>into my hd, e-mail, or business..?? Or @ least make it a serious pain in their
>ass to have even tried..??
>
>
>
There is no way anyone can use a Law Enforcement Access Field attached
to your files if you don't use software that puts one there. There is
no lawful basis for demanding that any software sold in the US do so.
On the other hand, the cracking "workfactor" of your encyption
(assuming you use ciphers like 3DES) will be the "guessability" of
the passphrase you choose (a lot less than 168 bits, with or without
hints gathered from papers in your trash), unless it can be bypassed
by forensic data recovery attacks (in which case it's zero bits).
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE
with Forensic Software Countermeasures
http://www.cerberus-sys.com/~infosec/
================================================
------------------------------
From: [EMAIL PROTECTED] (Albert P. Belle Isle)
Subject: Re: Cracking 128bit
Date: Tue, 02 Feb 1999 17:01:23 GMT
Reply-To: [EMAIL PROTECTED]
On 2 Feb 1999 06:30:37 +0100, Anonymous <[EMAIL PROTECTED]> wrote:
>I had been under the assumption that good 128 bit encryption
>would take billions of years to crack.
>But then I came across this
>
>http://www.securitydynamics.com/products/datasheets/securpc.html
>
>"...Cracking a single 128-bit RC4 key is an effort costing an
>estimated half billion dollars and taking more than six months to
>achieve."
This is a reputable company offering real numbers for someone wanting
to include the outside possibility of such brute-force attacks in his
cost-benefit analysis for buying INFOSEC products versus the value of
the data to be protected. Obviously, such attacks are the least of
most people's worries.
Anyone whose adversaries are dumb-enough to limit themselves to trying
to crack his (strong) cipher, rather than searching for statistical
weaknesses in his keystream generator, or more likely running
dictionary attack software against his passphrase (or not bothering
with any of it and "recovering" plaintext left on his hard disk), has
little to fear.
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE
with Forensic Software Countermeasures
http://www.cerberus-sys.com/~infosec/
================================================
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: Loony question
Date: Thu, 04 Feb 1999 22:41:22 GMT
Reply-To: Jim Dunnett
On 3 Feb 1999 18:50:57 GMT, [EMAIL PROTECTED] (Phillip George Geiger)
wrote:
>
>Would a particularly awful track off a CD with a lot of
>screeching guitars and howling monkeys be a decent source
>of random numbers?
>
>What sort of processing of the raw data would be appropriate?
Use two tracks from an unintelligible pop group.
XOR them to the length of the shortest. The result should
be random enough for all but the terminally paranoid.
You could do the same with two zipped files from a data
CD, but strip the header and the last few lines from
the files before XOR-ing them.
--
Regards, Jim. | I would be happy to see the devil's
olympus%jimdee.prestel.co.uk | buttermilk banned from Society.
dynastic%cwcom.net |
nordland%aol.com | - Iain Paisley, discussing Guiness.
marula%zdnetmail.com |
Pgp key: wwwkeys.uk.pgp.net:11371
------------------------------
** 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
******************************
