Cryptography-Digest Digest #738, Volume #10 Tue, 14 Dec 99 13:13:01 EST
Contents:
Re: Better encryption? PGP or Blowfish? (Tom St Denis)
Re: Better encryption? PGP or Blowfish? (Tom St Denis)
Re: Better encryption? PGP or Blowfish? (Tom St Denis)
Re: Simple newbie crypto algorithmn (Eric Hambuch)
Re: The Cracking of SecurityPlus! 4.32 (JPeschel)
Re: The Code Book (Paul Schlyter)
Re: Synchronised random number generation for one-time pads (Richard Herring)
"The Cracking of Security Plus" completed (JPeschel)
Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY)
Re: Why no 3des for AES candidacy (Eric Lee Green)
Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY)
how easy would this encryption be to crack? (Christoffer =?iso-8859-1?Q?Lern=F6?=)
How to implement different modes using the twofish algorithm? (Martin Bädeker)
Re: NSA should do a cryptoanalysis of AES (Derek Bell)
Re: NSA should do a cryptoanalysis of AES (Derek Bell)
Looking for a DES implementation in JavaScript or VBScript ([EMAIL PROTECTED])
Re: Are thermal diodes as RNG's secure (Tim Tyler)
Re: Data Encryption in Applet? (Tim Tyler)
Re: how easy would this encryption be to crack? (Jerry Coffin)
Re: Deciphering without knowing the algorithm? (Tim Tyler)
Re: Deciphering without knowing the algorithm? (albert)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Better encryption? PGP or Blowfish?
Date: Tue, 14 Dec 1999 12:58:55 GMT
In article <8345je$4v8$[EMAIL PROTECTED]>,
Phillip George Geiger <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : I was just being honest. People never think twice before launching
a
> : flame war when I am wrong. I know two wrongs don't make a right,
but
> : what other response could i give?
>
> You could have briefly explained why his question was a bad one, and
> pointed him at a FAQ.
>
> : His ignorant comparaison was just plain silly.
>
> And in the time it took you to think up that "witty" response, giggle
> like the child you are, and hit "enter" - you could have posted
something
> far more interesting and useful to a newbie.
But that's the thing, no one in sci.crypt cares about any real
scientific discussion, it's just a flame war waiting to happend.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Better encryption? PGP or Blowfish?
Date: Tue, 14 Dec 1999 13:04:07 GMT
In article <[EMAIL PROTECTED]>,
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
>
> Not always. Depends on the message space.
>
> Consider the reponse to a proposed contract. It can be encoded in a
bit.
> Any boolean message has this property. Some messages have even less
> information.
>
> Consider the case of a "Go!" command. The message itself contains
zero
> information. The recipient is waiting for exactly this message and no
> other. So the message consists of zero bits of plaintext plus
whatever
> authentication is necessary.
>
> Now consider the data rate of a channel used to transmit the Go!
message.
> Normally it has no data flowing through it, but there's a tacit
streams of
> "Not Yet!" messages that match the sampling rate of the receiver.
This data
> stream has no bits in it at all. Perhaps it has a stream of noise to
> reassure the receiver that a mesage hasn't been missed. But there's
no
> information in the noise. It's just noise.
>
> Tough to crack such virtual messages.
Ok true, I would not attack a message with 'Go!' in it. I would attack
the messages that described what they should go do.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Better encryption? PGP or Blowfish?
Date: Tue, 14 Dec 1999 13:02:23 GMT
In article <8348is$2g18$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> This just shows how fucking stupid you are little boy pain
> in the ass. Try reading what a ZERO Iinformation system is
> sometimes instead of opening your mouth. In a ZERO information
> protocall the seeds are in there to solve any encryption including
> that of a random file. IF you think mine has enough information
> for a random file break your not only full of shit but you know
> nothing about encryption. Try to learn something Tom becasue
> your posts are gettting dumber and dumber and it is getting
> frustracting wasting my time to try to improve your pee brain.
I will just go out invent this new attack called brute force. I will
win a nobel. If I can brute force any system, then that system has
given me enough information to break it.
And last time I checked most block ciphers fell into this category. No
matter how you use the block cipher, if the key is fixed, and used on
more then one block it can be attacked.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: Simple newbie crypto algorithmn
Date: Tue, 14 Dec 1999 14:08:35 +0100
Point 7:
for(i=0;i<256;i++) /* initialise sbox1 */
{ fibseq= ++fibseq % (FIBP+1);
fib[fibseq]= fib[(fibseq+1)%(FIBP+1)]
+ fib[(fibseq+(FIBP-FIBQ+1))%(FIBP+1)];
This seems to be useless. It doen't changes your key fib[255..606] und
only adds the
values from fib[325..] to fib[0..].
So this doen't make your algorithm stronger ! Delete this lines !
Eric
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: The Cracking of SecurityPlus! 4.32
Date: 14 Dec 1999 14:46:18 GMT
[EMAIL PROTECTED] writes:
>Nothing on Kremlin's implementation of IDEA? :) I must confess to
>having forgot my password for a file I encrypted long ago ...
The cracker Casimir did look at Kremlin for Mark Rosen.
Rosen writes:
"And there are scores of hackers out there ready to
disassemble and analyze any new encryption program.
For example, a hacker named Casimir has come up
with "cracks" for several popular encryption
programs, including "Crypt-o-text" and "Encrypt-It".
These cracks allow anyone to recover the contents
of an encrypted archive. When Mach5 Software
heard that he cracked Crypt-o-text and Encrypt-It,
we contacted Casimir and provided him with the
source code to Kremlin for analysis. But he didn't
crack Kremlin or find any weakness; he recently
e-mailed Mach5 Software and admitted defeat,
saying 'OK, you won. I surrender!'."
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: The Code Book
Date: 14 Dec 1999 14:38:44 +0100
In article <[EMAIL PROTECTED]>,
Warner <[EMAIL PROTECTED]> wrote:
> The first sentence of Simon Singh's _The Code Book_ is, "On the morning of
> Wednesday, 15 October 1586, Queen Mary entered the crowded courtroom of
> Fotheringhay Castle". The calendars I have referred to give this date as
> being on a Saturday. I'm interested in hearing comments on this apparent
> inconsistency or references to such.
You're probably right. The weekday of Gregorian 15 Oct 1586 was a
Wednesday, but in 1586 England was still on the Julian calendar. The
difference was 10 days.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: Synchronised random number generation for one-time pads
Date: 14 Dec 1999 14:36:20 GMT
Reply-To: [EMAIL PROTECTED]
In article <82pet6$cob$[EMAIL PROTECTED]>, Charles Meigh
([EMAIL PROTECTED]) wrote:
> Thanks everyone, I hadn't come across the problem of interception and
> forgery yet. I think I'll add a decent physics textbook to my shopping
> list as well as cryptology. I'm still thinking that there might be some
> vastly wide choice of 'celestial' events that could produce truly random
> numbers that will still be sufficiently similar observed from any two (or
> more) points on the globe, which would make OTP use more economical.
No. However you do it, you have effectively replaced the OTP key
by the description of where to find the random data. Since the
description is shorter than the data (or there would be no point in
doing it) you have reduced the keyspace and no longer have a OTP.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: "The Cracking of Security Plus" completed
Date: 14 Dec 1999 15:34:49 GMT
"The Cracking of Security Plus," by Casimir,
is now complete. You'll find the entire essay
on my site. Part C, the latest installment, includes
source code for a cracker, and a link to the
executable. The cracker is for versions
4.32 and earlier. You'll also find information
on 3 "encryption" programs that can be cracked
by applying a patch.
(As usual, this crack, and others, can be found
on the "Key Recovery" page.)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Deciphering without knowing the algorithm?
Date: Tue, 14 Dec 1999 16:29:47 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (HKXLF) wrote:
>Hi,
>I am new to cryptography although I am very interested in the subject. From
>browsing though this newgroup, I have come to a conclusion that, in order to
>decipher some message, all you need is to find the key. But how about the
>algorithm that is used the encrypt the text in the first place. Is it possible
>to decrypt some text without first knowing what algorithm is used to encrypt
>it?
>
Yes it is possible and it happens all the time. If one can recieve large
amounts of traffic that appears to have a patteren one con run test to see
what method was done. Fortunately for the NSA most mehtods in popular
use broadcast what is being used. IF one used PGP the message would
have PGP headers. Very few methods in popular use. Actually even bother
with encrypting files that are not multiples of various lengths so even the
file lengths give clues as to what system is being used.
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***
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Tue, 14 Dec 1999 08:49:33 -0700
"Douglas A. Gwyn" wrote:
> "SCOTT19U.ZIP_GUY" wrote:
> > The speed thing is what most phony crypto gods would have you belive the
> > reason is. But in fact with the bloated operating systems one uses know a days
> > and as machines get faster very week this is really a lame reaon when one
> > wants real security.
>
> Speed *is* important in order that encryption become as widespread as
> it really should, e.g. on network links. We're already in the age of
> fiber-optic communication.
Today's enterprise-class tape drives can handle streams of up to 40 megabytes
per seconds. The servers that feed these beasts may have multiple gigabit
Ethernet cards so that they can suck down enough data to keep the pipe full. I
looked at encrypting those streams with 3DES, since 3DES is a nice proven
algorithm, but it was just TOO BLOODY SLOW.
So this isn't a crypto god hypothesis (I'm no crypto god, I'm just an engineer
trying to create a solution). This is real world -- 3des is secure, but there
DO exist applications where it's too slow.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Deciphering without knowing the algorithm?
Date: Tue, 14 Dec 1999 16:42:53 GMT
In article <834g8r$ou0$[EMAIL PROTECTED]>, "Surface Mount" <[EMAIL PROTECTED]>
wrote:
>If you were to take a common algorithm for encryption, and modify it
>significantly, how hard would it be to decipher the message, assuming a good
>algorithm?
>
You might as well ask how many angels can dance on a pin.
Its kind of an oxyimoron to say "common algorithm for encryption"
and "good algorithm" there is no such animal in this closed society
government groups like the NSA spend billions to miseducate and
misled the public so no good methods are in common use.
Even the so called expert books on encryption are carefully
crafted so that you can be misled down the garden path.
There is one guy in this group who I will not name. I will
just refer to him as MR BS. Just take the example of the
use of compression in encryption. His book only mentions
it in passing in one place only to say that compress then
encrypt and the send the message where error hadling is
done by the sending protocal. Yet he in other pages
recommends useing various errory recovering types of
chaining that are of great use to groups like the NSA.
By the way if you use compression before encrypting
use one that adds no information to the file. The phony
crypto gods will not tell you this since it is a trade secret
they don't want the public to know.
Guess what that is the kind of compression I have at my
site. But you will find few references to it on the net.
Try this one experiment out for any file X check if
compress(decompress(X))=X and if decompress(compress(X))=X
Try this with any other real compression program. Hint removing
the common headers is not going to be enough.
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***
------------------------------
From: Christoffer =?iso-8859-1?Q?Lern=F6?= <[EMAIL PROTECTED]>
Subject: how easy would this encryption be to crack?
Date: Tue, 14 Dec 1999 17:02:53 +0100
I'm using a rather simple encryption scheme and I'm kind of wondering
how easy it would be to crack,
if anyone'd like to take a look at it I'd be very happy:
In Java the algorithm would look something like this:
public byte[] encrypt(byte[] bytestoencrypt,byte[] keya,byte[] keyb)
{
byte[] out=new byte[bytestoencrypt.length];
int spin=keya[keya.length/2]+keyb[keyb.length/2];
int apos=0;
int bpos=0;
byte currenta;
byte currentb;
int somenumber=1973;
for (int i=0;i<encryptedbytes.length;i++)
{
currenta=keya[apos++];
if (apos>=keya.length)
{
apos=0;
}
currenta+=spin;
currentb=keyb[bpos++];
if (bpos>=keyb.length)
{
bpos=0;
}
spin+=currentb;
while (spin>somenumber)
{
spin-=somenumber;
}
out[i]=(byte) (bytestoencrypt[i]^currentb)^currenta);
}
return out;
}
keya & keyb would have different length, for example keya would be 1
byte longer than keyb
Too easy to crack?
/Christoffer
------------------------------
From: Martin Bädeker <[EMAIL PROTECTED]>
Subject: How to implement different modes using the twofish algorithm?
Date: Tue, 14 Dec 1999 16:44:24 +0100
Reply-To: [EMAIL PROTECTED]
Hello!
I'm a newbie to this and have problems to implement following modes of
Twofish: CFB1,CBC,ECB. I already verified - using given testvectors -
that my implementations of makeKey, BlockEncrypt and BlockDecrypt are
delivering the valid outputs, but I can't get proper results in CBC
mode.
For CBC I XORed the plaintext (PT) and the IV and at then encrypted it
using my function. But the resulting ciphertext (CT) differs from the
CBC testvectors.
CT = Encrypt(PT xor IV)
Any suggestions?
Thx, Martin
==========================================
For replying delete NOSPAM in the address!
------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: 14 Dec 1999 16:29:02 -0000
karl malbrain <[EMAIL PROTECTED]> wrote:
: Again, that's the exact same SUBJECTIVE point. It's just a round-about way
: of OBJECTIVELY DEMANDING more money go to bomber manufacturers. The first
: `bombers' in WORLD WAR I were just STANDARD bi-planes. Karl M
Bombers are designed with very different criteria in mind than an
airliner would. Stealth being one famous example for a few types of bomber;
another being that bombers have fewer "air rage" incidents with passengers.
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: 14 Dec 1999 16:25:31 -0000
Tony T. Warnock <[EMAIL PROTECTED]> wrote:
: Actually they've been doing this with luggage for years.
All of them, or just the one that says "we send your luggage
everywhere"? ;-)
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Looking for a DES implementation in JavaScript or VBScript
Date: Tue, 14 Dec 1999 16:38:41 GMT
Wanted to see if it is available before I start working on it.
any reply appreciated.
RG
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Are thermal diodes as RNG's secure
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Dec 1999 17:09:31 GMT
Scott Nelson <[EMAIL PROTECTED]> wrote:
: On Mon, 13 Dec 1999 16:58:56 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Bill Unruh <[EMAIL PROTECTED]> wrote:
:>: [EMAIL PROTECTED] (Lincoln Yeoh) writes:
:>[removing biases from hardware sources of randomness]
:>
:>: ]How can we cook such output?
:>
:>: Eg, if you suspect that the output is not really random, but is
:>: "partially" random, so that say a fraction f of the information really
:>: is random,then you could feed say 128/f bits into a hash function like
:>: MD5 and use the 128 bits of output. That output should be "fully"
:>: random.
[hash functions for distilling randomness]
:>If any practical hash were as good at distilling entropy as this,
:>it would be a miracle.
: If the hash produced a random (rather than evenly distributed)
: 128 bits based on the input 128/f bits, then the number of states
: would only be 1/e*2^128. That sounds bad, but it's less than
: 2 bits off of perfect, or under 2% error. Secure hash
: functions aren't perfect, but they are very good.
My problem with what you write here is that I doubt your premise.
***IF*** the hash produces a random 128 bits based on the input
(i.e. from a huge lookup table of high quality, hardware-generated
random numbers) - it would no doubt be as good as you say.
However, hash functions can't /possibly/ employ such huge tables -
they have to simulate them using mathematical techniques.
I'd be happy to imagine a uniformly distributed hash function - and
it would still be likely to fail to create fully random output - even
from a mountain of biased input.
The comparison with pseudo-random number generators still seems
appropriate to me:
PRNG output has a lower entropy than a real random stream. The entropy of
the stream is only that of the original seed.
Similarly, hashes based on pseudo-random functions - rather than genuinely
random ones - will not do as good a job of concentrating the entropy as
they could do.
The original data is patterned (that's why we're using a hash in the
first place - to introduce more randomness).
The hash itself is also patterened (as it's made up of a relatively small
function, rather than a huge random LUT). If the types of pattern happen
to be anything other than completely orthogonal, that might cause
problems for the ability of the hash to concentrate the entropy from the
message.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The second mouse gets the cheese.
------------------------------
Crossposted-To: comp.lang.java.security,comp.lang.java.programmer
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Data Encryption in Applet?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Dec 1999 17:29:20 GMT
In more than one place, Chris Wolfe <[EMAIL PROTECTED]> wrote:
: I see a big, big problem with that key distribution. By definition if
: the key can be decrypted using your public key, than anyone who
: intercepts the transmission can decrypt it.
You're correct to point out this problem with Brian's proposal.
Conventionally, messages may be *encrypted* with the public key,
but can only be *decrypted* with the private key.
Consequently - as you suggested - the applet can generate a key for the
symmetric cypher, encode the message with it, and then encrypt it's key
using the server's private key. It then sends everything to the server.
The server can decrypt the resulting message, using the private key.
The problems with this type of system involve authenticating the
server - and making sure the Java applet is not replaced in transit
to you by one developed by an attacker, which posts your private
message to the recipient of its choice.
*If* you can verify the applet is from who it says it is from
(using a public key-based digital signature scheme), then the
scheme is an interesting one.
Completely destroying the generated key for the symmetric algorithm on
the client (i.e. making sure it is not resident in a swap file
somewhere when the applet quits) is one problem. AFAIK, Java has no
support for making this possible, besides crude attempts to overwrite what
is hopefully the same memory with random values.
Certainly any encryption built into browsers is likely to get lots of
attention from people with time on their hands. Using a Java applet
and your own cryptography is one way of dealing with the browser's
encryption being a juicy target.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
What if I /want/ the one in the bush?
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: how easy would this encryption be to crack?
Date: Tue, 14 Dec 1999 10:46:34 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> I'm using a rather simple encryption scheme and I'm kind of wondering
> how easy it would be to crack,
> if anyone'd like to take a look at it I'd be very happy:
[ a double substitution cipher ]
> keya & keyb would have different length, for example keya would be 1
> byte longer than keyb
>
> Too easy to crack?
The effective key length is (at most) the GCD of the lengths of the
two keys. Assuming they're relatively prime, that means the product
of their lengths. E.g. if they were 5 and 7 bytes long, then the
effective key length would be 35 bytes.
If the text you encrypt with a particular pair of keys is 10 times (or
so) as long as the effective key length, breaking it can be done very
quickly and usually completely automatically.
If you encrypt less than that, it can still be pretty easy to crack
unless you're fairly careful. For example, if you normally have a
"To:" and "From:" at the beginning of your message, and a signature-
like block at the end, this will help the cryptanalyst crack your
encryption with substantially less text.
Against a threat-model like known-plaintext or chosen-plaintext, this
provides essentially no security at all -- once the text you've
encrypted is just over double the effective key length, the repetition
of the key is obvious.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Deciphering without knowing the algorithm?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 14 Dec 1999 17:39:48 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: Very few methods in popular use. Actually even bother with encrypting
: files that are not multiples of various lengths so even the
: file lengths give clues as to what system is being used.
This cuts both ways. If most commonly used techniques spit out a file
that is a multiple of 64 bits in length, it's not easy to tell such
techniques apart.
On the other hand, if you are using a rare method - that needs no padding
and can cope with arbitrary-sized files - the length of the file will
frequently tell the attacker that such a technique is in use.
The moral of the story is probably to try to pad your messages with a
quantity of random garbage (to disguise their real length) after
encryption.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I have seen the truth - and it makes no sense.
------------------------------
From: albert <[EMAIL PROTECTED]>
Subject: Re: Deciphering without knowing the algorithm?
Date: Tue, 14 Dec 1999 09:46:30 -0800
First, every element in an algorithm should be there by design only, there
should be no reason to have something in an algorithm (especially a crypto one)
unless there's good justification that adds to the overall security of the
algorithm. So when you "modify" it, it usually weakens, not strengthens an
algorithm.
To address the original question; Patterns are easily found in badly written
algorithms, so it's quite possible and happens often that an algorithm is broken
without actually knowing the algorithm. Remember though, that's called security
by obscurity, or security by stupidity as it's often referred to. The security
of an algorithm should lie in it's design, not the fact that the enemy doesn't
know about it. Alice should pick an algorithm the rest of the world knows and
has been thoroughly studied by the best cryptoheads in the world. That's the
only way Bob is going to feel comfortable about the method used...
Albert
Surface Mount wrote:
> If you were to take a common algorithm for encryption, and modify it
> significantly, how hard would it be to decipher the message, assuming a good
> algorithm?
>
> Arthur Dardia <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Yeah. Just try every single algorithm. Decrypting a message given a key
> is
> > rather fast. However, a "secret" algorithm cannot be guessed very easily.
> >
> > HKXLF wrote:
> >
> > > Hi,
> > > I am new to cryptography although I am very interested in the subject.
> From
> > > browsing though this newgroup, I have come to a conclusion that, in
> order to
> > > decipher some message, all you need is to find the key. But how about
> the
> > > algorithm that is used the encrypt the text in the first place. Is it
> possible
> > > to decrypt some text without first knowing what algorithm is used to
> encrypt
> > > it?
> > >
> > > Anyway, I'll be grateful if anybody can satisfy my curiosity.
> > > Thanks,
> > > Herry.
> >
> > --
> > Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
> > PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
> >
> >
------------------------------
** 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
******************************
