Cryptography-Digest Digest #249, Volume #11 Fri, 3 Mar 00 23:13:00 EST
Contents:
Re: Can someone break this cipher? (Xcott Craver)
Re: Can someone break this cipher? (Xcott Craver)
Re: Best language for encryption?? ([EMAIL PROTECTED])
Re: brute force attack on a 128 bit SSL key? (Michael Sierchio)
Re: Crypto.Com, Inc. (Tony L. Svanstrom)
Re: NIST, AES at RSA conference (John Savard)
Decompiling/Tamper Resistent ([EMAIL PROTECTED])
Re: NIST, AES at RSA conference (John Savard)
Re: Decompiling/Tamper Resistent (Rainy Mokle)
Re: Random bit generators ([EMAIL PROTECTED])
Re: are self-shredding files possible? (Paul Koning)
Re: Key escrow and echelon (Paul Koning)
Re: On jamming interception networks (Paul Koning)
Re: Decompiling/Tamper Resistent (Andru Luvisi)
Re: Cellular automata based public key cryptography (SCOTT19U.ZIP_GUY)
Re: IDEA question. (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: Can someone break this cipher?
Date: 4 Mar 2000 01:04:22 GMT
Mary - Jayne <[EMAIL PROTECTED]> wrote:
>
>It is quite likely that no-one will ever *try* to break it however :-)
Quite likely. As the FAQ says, a challenge merely providing people
with ciphertext will often not be taken seriously. Providing
a description of the algorithm --- usually source code or pseudo-
code --- is required so people can analyze the cipher's security.
Note that providing a description of the algorithm doesn't just
mean providing a few general statements about how it works. It's
got to be so explicit that analysts can at least write the source
code themselves.
If you just provide ciphertext, then you're not asking people
to break the cipher itself. If you want to stress-test the
security of the _cipher_, then you must provide the _cipher_,
not text output by it.
==- Xcott Craver -- [EMAIL PROTECTED] -- http://www.math.niu.edu/~caj/ -==
"Also note that elecronagnetic theory proves that if you microwave a
bar of Ivory soap it turns into a REAL MARSHMALLOW THAT YOU CAN EAT."
-James "Kibo" Parry
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: Can someone break this cipher?
Date: 4 Mar 2000 01:21:19 GMT
Mary - Jayne <[EMAIL PROTECTED]> wrote:
> Mark VandeWettering <[EMAIL PROTECTED]> wrote:
>
>>A copy of the program source code would be in order. It seems rather unfair
>>for you to ask people to analyze your algorithm without the source code to
>>find weaknesses that you can't with the source code.
>
>Dream on.
Please, PLEASE read the newsgroup FAQ _before_ posting anything.
If you don't provide the algorithm, people will not analyze your
cipher. You don't have to provide source code, maybe just
pseudo-code. Explicit formulas would be fine too. Enough so we
could write our own source if we had to.
It is _possible_ for people to crack a cipher without knowledge of
the algorithm, but they must waste a considerable amount of extra
time to do so. This extra time says nothing about the cipher,
because a cipher should be secure even if attackers have the
source code. Experts won't respond to such an unreasonable request
without a really, really good reason.
Not giving out the algorithm almost as bad as not giving out
the ciphertext! Might as well lock the ciphertext in a safe
in your home and then dare cryptographers to crack it. The
safe, like your refusal to provide the details, is only an extra
inconvenience, an attempt to impede efforts to find the flaws.
You're asking people to do you a favor, to analyze your cipher;
why then inconvenience them so?
-X
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Best language for encryption??
Date: Sat, 04 Mar 2000 01:30:05 GMT
It was considered years ago that languages like Pascal and C were weakly
typed. Ada came along with a big promise..but has not found widespread
acceptance...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: brute force attack on a 128 bit SSL key?
Date: Fri, 03 Mar 2000 17:41:33 -0800
Bob Silverman wrote:
> *Thankfully* there are a few people who can do arithmetic.
>
> *Unfortunately*, too many people (who clearly have no clue what they
> are talking about) have posted misinformation on this topic.
You mean the topic of a brute force attack against a 128-bit
symmetric cipher? ;-) (it's still in the subject line).
Anyway, I stand by my arithmetic -- esp. my dollar-year figures
for the brute force keyspace search. Even if Moore's law holds
it will be infeasible 50 years from now.
------------------------------
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Subject: Re: Crypto.Com, Inc.
Date: Sat, 4 Mar 2000 02:44:06 +0100
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> >
> > <[EMAIL PROTECTED]> wrote:
> >
> > > Another possibility: Telepathy! Believe it or not, it was only a few
> > > days ago that pre-cognition of animals and such stuffs were earnestly
> > > discussed in a French radio broadcast.
Animals can spend a long time before we can detect an earthquake being
very very afraid; and that is just as much "magic" as telepathy would be
to us. Looking into such matters we can either, at the end, learn
something fantastic that will make the "magic" true science, or we might
learn something about how we read data when we know what the result will
be. In either case we've taken something unknown and made it known
instead of just pushing it aside.
> > Do you suppose that we can better communicate with BXA this way, or is
> > that the technique they are trying to use in lieu of seeding email to
> > us.
>
> I consider it a sad fact that in the 21st century there is still quite an
> amount of people who more or less believe such pseudo- sciences.
Well, just like we today can't prove that [your favorite algorithm that
has no publicly known weakness] hasn't been broken by [your favorite
TLA] we can't prove that telepathy doesn't work. You won't catch me
runing around thinking that some TLA is reading my mind, but I think
that it's important that we keep our minds open for new things because
of what we might discover.
Try to prove that telepathy works and you might end up learning
something new about how our brain reads bodylanguage, try to prove that
there exists empaths and you might learn something about how we without
noticing it can use a persons voice to detect the current mental state
of that person.
See, I just took some "pseudo-sciences" and showed how it could result
in valuable knowledge within "real" science. I'll be the first one to
admitt that these examples weren't the best, but I don't think that'll
stop you from understanding what I meant to say.
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---ôôô---ôôô-----------------------------------------------ôôô---ôôô---
\O/ \O/ ©1999 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Fri, 03 Mar 2000 19:05:48 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote, in part:
>``An important element in the security architecture of Crypto AG is the
> customer’s independence from the manufacturer’s design. It is based on
> manipulation-proof security chips and individual ASICs with proprietary
> mathematical algorithms. Because of this design, the user - and only the
> user - controls the vital parts of the modern algorithms and
> consequently gains effective autonomy. This provides the same level of
> independence as leading industrial nations which use proprietary
> algorithms geared to their defence or government requirements.''
Well, allowing the user to alter the algorithm, within limits, is a
good idea.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Decompiling/Tamper Resistent
Date: Sat, 04 Mar 2000 01:47:32 GMT
In order to protect our intelectual property (software) from decompiling
freaks, we need to build our crypto software in a tamper resistent
device for our network crypto cards.
Any advice on how this may be done?. Is this some kind of special
EEPROM or a sealent in the box?
I have not been able to find any web sites which deal with this subject.
Is it the semiconductor manufacturers who offer this kind of technology?
TIA
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Fri, 03 Mar 2000 19:12:18 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote, in part:
>They /seem/ serious.
>
>http://www.crypto.ch/english/company_folder/crypto_com_cryptoie.html
produced only general comments about the company. In trying to find
the quote you gave, I found a number of serious things wrong with
their web site.
Index tabs at the top had (Empty Reference!) at the end. The main
index page didn't exist - it was completely blank, though, not a 404.
Parts of the site I remembered are there, but a lot seems to be
missing.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Rainy Mokle)
Subject: Re: Decompiling/Tamper Resistent
Date: Sat, 04 Mar 2000 02:10:33 GMT
[EMAIL PROTECTED] wrote:
>In order to protect our intelectual property (software) from decompiling
>freaks, we need to build our crypto software in a tamper resistent
>device for our network crypto cards.
You want to offer a cryptography product for sale, and you intend to go to
extraordinary lengths to prevent people from investigating its inner
workings and confirming its security?
How incredibly clueless!
--
"Rainy Mokle" is actually [EMAIL PROTECTED] (5279 314860).
01234 56789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Random bit generators
Date: Fri, 03 Mar 2000 18:39:15 -0800
What exactly are you replying to?
Joseph Ashwood wrote:
> Suggestions similar to this come up quite often. And the
> only conclusion that can be derived from it without knowing
> the functions involved is to say that there exists an
> optimal function f() that is equivalent to your suggestion,
> and that your security depends solely on the security of
> that function. OTOH your speed does not, your speed will not
> be optimal. I suggest that if you are truly interested in
> the security of such a method you find the function f() so
> that it can be accurately reviewed, by you and others.
> Joe
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Mon, 28 Feb 2000 11:36:30 -0500
Michael Sierchio wrote:
>
> "Jeffrey A. Six" wrote:
> >
> > You can never "permanently and securely" delete files in the way you
> > describe. Once the file is opened, or decrypted, the plaintext, or the
> > contents of the file, are visible. Once this is true, that data can be
> > saved out in some form.
>
> You're describing a deliberate act of sabotage. But files can certainly
> be deleted in the manner described, even without an embedded executable.
>
> See http://www.disappearing.com/
>
> The current business solution they currently offer is email retention/
> automatic deletion, but the technology is applicable to any type of
> electronic document.
Sure, that's what the PR fluff says. But where's tbe beef? If you
have a backup copy the message clearly hasn't disappeared. If you have
a backup copy plus a search warrant, clearly the message will be
produced
even if the supposed time period is gone.
The reality is that what's being asked for is impossible. You *cannot*
create electronic messages that "turn to dust" after some time. The
best
you can do is create a set of *procedures* that are uncooperative when
someone attempts to get the message later, but there are limits to
how uncooperative you can be when you're up against government power.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Key escrow and echelon
Date: Mon, 28 Feb 2000 11:50:14 -0500
hev wrote:
>
> Some PKI vendors are big on Key escrow, the storage of encryption keys
> in a "secure location." Some of these PKI vendors have intimate
> relationships with big Echelon players (Defense Canada, NSA, DoD, M15
> etc). I've always wondered if these three letter agencies could get into
> the private key repositories. You may think you have a secure connection
> with your PKI or VPN, but if someone has access to the private
> encryption keys, you are screwed.
PKI suppliers have no need to see your private key. In fact, no one
has.
Don't give it to anyone. Don't do business with someone who asks for
it,
because they are surely very confused if they do...
I haven't seen PKI vendors that are "big on Key escrow" as you claim.
That makes sense, because it would be professional/commercial suicide
to take that position.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Mon, 28 Feb 2000 11:46:27 -0500
Mok-Kong Shen wrote:
>
> Recently in another thread I commented that interception networks
> could be rendered inoperable if everybody of the world encrypts
> his/her messages, whether text, voice or images, thus exhausting
> the agencies' (huge but finite) computing resources to analyse
> these.
>
> In a private communication it was correctly pointed out to me that
> my suggestion evidently entails too much work for the people to do
> and hence the idea is useless practically.
I don't see why that is true. Yes, if it requires manual action,
say running PGP on every email you send, maybe so. On the other
hand, the FreeS/WAN project (IPSec for Linux) aims to do exactly
what you describe as impractical.
paul
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Decompiling/Tamper Resistent
Date: 03 Mar 2000 19:21:35 -0800
[EMAIL PROTECTED] writes:
> In order to protect our intelectual property (software) from decompiling
> freaks, we need to build our crypto software in a tamper resistent
> device for our network crypto cards.
>
> Any advice on how this may be done?. Is this some kind of special
> EEPROM or a sealent in the box?
You can't. And even if you could, it would be a bad idea, since it
makes your product less valuable to people who purchase it.
> I have not been able to find any web sites which deal with this subject.
There's a reason. See above.
> Is it the semiconductor manufacturers who offer this kind of technology?
Nope. No one does. One of the closest things you'll find is "smart
cards", and they still aren't tamper "proof".
As Bruce Schnier put it, maintaining a secure perimeter when you have
armed guards who can arrest and shoot people who violate it is much
easier than attempting to create a secure perimeter that people can
take home, and do whatever they like to, unsupervised.
Furthermore, if your product "loses" security once someone knows how
it works, it was never secure to begin with.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cellular automata based public key cryptography
Date: Sat, 04 Mar 2000 04:34:42 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>I've recently developed an interest in public key cryptography based on
>cellular automata.
>
>This was pioneered in the 1980s by the Chinese cryptographer, Tao Renji.
>
>I've compiled a bibliography of his work at http://alife.co.uk/ca/taorenji/
>
>Since this work was largely published in Chinese - and is thus not
>terribly accessible to me - I've redeveloped the basic ideas behind the
>system.
>
>A preliminary description of my explorations is available on the web.
>
>The basic idea is a technique for generating reversible finite automata
>whose inverses have domains that are unboundedly large.
>
>This technique generates "quasi-linear" automata with "weak" inverses.
>
>I describe this technique at http://alife.co.uk/ca/largeinverse/
>
>This technique can be used as the basis of a public key cryptosystem:
>
>The basic idea involves generating two finite invertable cellular automata.
>At least one of the automata should contain a significant number of
>non-linear components. The two automata are combined, to form a third
>automata which is then published as the public key.
>
>Combining the two automata is done by creating a third automata
>which is equivalent to applying them in sequence. This is done by
>algebraic combination, and expanding out the resulting terms.
>
>To encrypt data, it is passed through the published automata.
>
>To decrypt, the inverses of the two automata are applied in sequence.
>
>This relies on the fact that finding the inverse of the public automata
>- without knowledge of its components - is a difficult problem.
>
>It can be difficult to decompose a composite automata into its component
>parts - in very much the same way that it is difficult to factor the
>product of two large primes.
>
>http://alife.co.uk/ca/publickey/ describes the proposed process in
>a little more detail.
>
>I have not yet built any sort of system based on these ideas.
>
>It appears that the resulting system should work /extremely/ rapidly when
>implemented in appropriate hardware - but may have large keys.
>
>I have not yet managed to read a single one of Tao Renji's papers, or
>any of those cryptanalysing his system. /All/ my knowledge of his work
>comes from the pages of "Applied Cryptography" (2nd ed. p.500) :-(
>
>I am keen to learn more about the original work, so I can avoid
>duplicating it, and to learn from previous exploration of the area.
>
>If anyone can help me by providing me with details that I do not already
>have access to, that would be very helpful. For example, if there are any
>books in print containing any of the papers in my bibliography, I'd be
>interested to learn about this.
>
>I do not yet have much familiarity with other public key cryptosystems.
>
>If there are other methods - which do not rely on large prime numbers,
>the discrete logarithm problem, etc - and which might bear some possible
>relationship to the system I describe - a pointer might be useful to me.
>
>Any comments about the proposed system would also be welcomed.
>
>Please don't advise me that my descriptions are currently vague and
>incomplete, though - since I'm aware of that already.
Tim I like the idea. I will be getting a new machine in a few weeks. It will
be faster and have more memory so I can start working on compression
and encryption and this also looks interesting since I think you are really
for good encyption not like the phony crypto gods who post on here once and
a while.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: IDEA question.
Date: Sat, 04 Mar 2000 03:31:15 GMT
In article <[EMAIL PROTECTED]>,
Volker Hetzer <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > A better approach is to attach a hash of the file [and encrypt the
> > hash] so when you decrypt the file and the hash, the hash should
match
> > up. This way there are no known blocks and you can tell if it
worked.
> Or, even better, use HMAC.
>
True.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
