Cryptography-Digest Digest #477, Volume #12      Fri, 18 Aug 00 16:13:00 EDT

Contents:
  Posting an encrypted message ("Steve")
  Re: Just a thought... ("Paul Pires")
  Re: Symmetric Encryption and Decryption (Mok-Kong Shen)
  Re: Cryptography and Content Protection (Adriano Prado)
  Re: Cryptography and Content Protection (Adriano Prado)
  Re: Posting an encrypted message (Mok-Kong Shen)
  Re: IDEA Test Vectors (Mark Wooding)
  Re: blowfish problem ("Donald L. Nash")
  Re: Cracking RC4-40 in FPGA hardware (Paul Rubin)
  pRNG, ECC and block modes (Rich)
  Re: How to design a new *secure* network protocol from scratch? (proton)
  Re: blowfish problem (Ben Pfaff)
  Re: pRNG, ECC and block modes (Mok-Kong Shen)
  Intermittent stream cipher? ("mconroy")

----------------------------------------------------------------------------

From: "Steve" <[EMAIL PROTECTED]>
Subject: Posting an encrypted message
Date: Fri, 18 Aug 2000 12:08:15 -0500

Is there a place where one can post a message which has been encrypted
and others can retrieve it and attempt to decipher it.???  I know that
the longer the message the more information one has available
internally to try to figure out the plain text. What would be a
recommended minimum length of a message in characters to work on if
anyone does this kind of thing.  1,000  -  2,000  -  10,000
characters.. I have one I'd like to post and see what someone can do
with it.

My thinking is if someone can decipher the message then my
system/program for encrypting it is flawed..  It is nice to see
everyone is talking about primes, randomness, 2**<32>, Public Key,
etc. etc. but isn't the real test of a system or message the fact that
only you and the recipient can read it.  Granted there are probably
flaws in everything but if it is going to take 2 years to break the
message and 10 days from now the information is worthless or the event
is history, then you have accomplished the mission.

If I create a program which takes 6 months to crunch out the actual
message then I know the limit of what it can provide. Even if I change
the key in each message and your knowing the general scope of the way
it was encoded it takes 6 months to decipher then for <some> things it
is quite secure using. Does anyone rate programs on general <time>
aspects for security.  And if someone actually breaks the programs
secure properties then the TIME factor is updated from weeks or months
to hours or it is now considered obsolete....???

A question:  I talked about using the KL-7 rotor based mechanical
enciphering machine recently. Can anyone tell me with any <accuracy>
how secure it is in today's market if you knew that the message you
had was encoded with that system.. 2 hours, 2 weeks, 6 months...???  I
would assume that even if you had a machine in front of you the
physical setup and changing would render it secure for weeks, probably
months.

Don't get me wrong we have to have a forum like this one to discuss
and work out problems and exchange ideas. I guess I am new enough to
this list that I haven't seen enough <elsewhere's> to go for some
things.

Thanks,  Steve





------------------------------

From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Just a thought...
Date: Fri, 18 Aug 2000 10:12:39 -0700


Simister, Shawn [SKY:0000:EXCH] <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]...
> I've been wondering whether it would be viable to create an encryption
> algorithm whose strength would be based upon the fact
> that it could only be broken by a brute force attack and that the
> encryption/decryption process took so long that going through
> every possible key would take wayto long.

This is the case now.

>
> Example:
>
>       The encrypt/decrypt algorithm is designed so that it takes at
> least 0.005s per byte (on a  dual P III   600) no matter how it's
> programmed.
>      The key size is 50 bits long.
>
>         Therefore...
>
>      A 1 MB file would take approx. 1.4 hours to encrypt/decrypt.
>      If 5 million computers (dual P III 600) attempted to crack this
> file using a brute force method (ei. Decrypting the cipher text with
> each key and comparing it to a copy of the plain text) it could take
> them as long as 36, 000 years.

You have unprovable conditions already. How do you prove that it can't be
run faster according to a faster process? How do you prove that it cannot be
hacked faster than brute force?

If you loose your "Provably secure" argument, why not use Blowfish?

Using 50 bits of key is just maddness. You're betting everything on the roll
of the dice. Your 36,000 years isn't very good for long term security since
it is based upon current computing power. If you looked at a good
contemporary algorithm (using a decent key) against current computational
abilities, the time figure is meaningless and can only be related as
multiples of the estimated lifespan of the universe. You got to get a grip
on the scope here.

Paul


>
>         Obviously there are some cases in which this would be far to
> time consuming for the sender and receiver, but if this were
> proven to be 100% secure I'm sure there would be some parties who would
> be willing to make these kind of sacrifices.
>
>         The question comes to mind, why would anyone use this algorithm
> when there are already much quicker algorithms which
> have yet to be proven faulty. I guess it's just cause I've been thinking
> about this for a while and I have the distinct feeling that
> there is something I am overlooking.
>
>         If anyone has heard of this kind of thing before or knows of any
> papers related to this It would be much appreciated.
>
> Thanks in advance!
>
> Shawn Simister
>





------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Symmetric Encryption and Decryption
Date: Fri, 18 Aug 2000 19:45:04 +0200



"Koon Kin Hin, Kenny" wrote:
> 
> 1. Can anyone tell me the process of Symmetric Encryption and Decryption in
> detail?
> 2. How can a smart card can perform processing function by itself?

The best is that you read a standard text on cryptography,
e.g. Schneier's AC or Menezes' HAC. A smart card has an 
embedded microprocessor.

M. K. Shen

------------------------------

From: Adriano Prado <[EMAIL PROTECTED]>
Subject: Re: Cryptography and Content Protection
Date: Fri, 18 Aug 2000 17:39:19 GMT

Ok, let me be clearer...

What is my 'system':

Alice is a point-of-sale printer (the one used in supermarket).
Bob is a computer.

What I need:
The printer respond to a set of defined commands.
This commands are sent by the computer via a RS-232 serial port.

There are some of these commands that are restrict, the computer has
to send a key that is unique to each printer so it can be accepted.
That is, the same computer communicates with more than one printer,
but for each one it has to send a specific key.

So, if one wants to use such set of commands, he has to call me,
send the serial number of the machine, and then I compute the key.
I pass the key by fax or e-mail. He then enter with the key in the
communication program who will send (the key) to the printer.
The printer should be able to see if the key is right for its serial
number.

capisce?


thanx!!!!


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Adriano Prado <[EMAIL PROTECTED]>
Subject: Re: Cryptography and Content Protection
Date: Fri, 18 Aug 2000 17:39:13 GMT

Ok, let me be clearer...

What is my 'system':

Alice is a point-of-sale printer (the one used in supermarket).
Bob is a computer.

What I need:
The printer respond to a set of defined commands.
This commands are sent by the computer via a RS-232 serial port.

There are some of these commands that are restrict, the computer has
to send a key that is unique to each printer so it can be accepted.
That is, the same computer communicates with more than one printer,
but for each one it has to send a specific key.

So, if one wants to use such set of commands, he has to call me,
send the serial number of the machine, and then I compute the key.
I pass the key by fax or e-mail. He then enter with the key in the
communication program who will send (the key) to the printer.
The printer should be able to see if the key is right for its serial
number.

capisce?


thanx!!!!


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Posting an encrypted message
Date: Fri, 18 Aug 2000 20:12:06 +0200



Steve wrote:
> 
> Is there a place where one can post a message which has been encrypted
> and others can retrieve it and attempt to decipher it.???  

See FAQ 2.3 (last posted on 11th Aug).

M. K. Shen

------------------------------

From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: IDEA Test Vectors
Date: 18 Aug 2000 18:26:17 GMT

Mark Wooding <[EMAIL PROTECTED]> wrote:

> The fact that addition is also only done between (zero) key words and
> text words, and is therefore a no-op in this case, is just icing on the
> cake.

Whoops.  This is wrong.  The adds in the MA block are between two chunks
of text.  It still ends up being awful.

-- [mdw]

------------------------------

From: "Donald L. Nash" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Fri, 18 Aug 2000 13:25:20 -0500

In article <8njg8f$no5$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul 
Schlyter) wrote:

>Actually, the CDC 6600 had an altneraive character encoding, which
>used 12 bits ber character.  In CDC jargon, this was called "ASCII",

Here at UT (where we had a 6600 and a 6400, and then two Cyber 750s by 
the time I came along), it was called "8-in-12 ASCII" for obvious 
reasons.  I don't know if this was a local UT nomenclature or something 
from CDC.

-- 
Donald L. Nash, <[EMAIL PROTECTED]>, PGP Key ID: 0x689DA021
The University of Texas System Office of Telecommunication Services

------------------------------

From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Cracking RC4-40 in FPGA hardware
Date: 18 Aug 2000 18:40:29 GMT

In article <8njadj$[EMAIL PROTECTED]>,
Paul Morris <[EMAIL PROTECTED]> wrote:
>I am also considering the possibility of researching a different idea. This
>device would contain a built in RNG which would produce keys for a suitable
>cipher. This key would be stored within the device and protected from
>removal by normal security safeguards (physical security of the device etc).
>The device would produce an 'access' key which would enable
>decryption/encryption of data using the 'data' key. I thought this might be
>a useful device because of the fact that the actual key is fully random and
>known to no-one except the device. Therefore the device is required for all
>transactions which can provide more security for the organisation, since
>access to a box can be usefully restricted. What does anyone think of this?

It's a useful thing, but not very interesting.  You can buy off the
shelf chips that do it for a few USD.  I don't think it would be
substantial enough to be a course project.  It would be a good weekly
homework assignment.

------------------------------

Subject: pRNG, ECC and block modes
From: [EMAIL PROTECTED] (Rich)
Date: Fri, 18 Aug 2000 18:43:40 GMT

Hello group, as a long-time lurker I've learned quite a lot and very much
appreciate all the discussions. I now have a few questions, which I hope 
you folks can weigh in on. There are as follows:

1. Which pseudo-random-number-generator is the "Best"?: Yarrow; Blum-Blum-
Shub; Micali-Schnorr or Wichmann-Hill?

2. Which one-way hash is the "Best"?: Havel; SHA-2; DHA; Tiger; Ripemd-160;
Blum-Blum-Shub; Meyer-Davis; or GOST 34.11-94?

3. Which Message Authentication Cert. is the "Best"?: H-MAC or D-MAC?

4. Which Error-Correction Code is the "Best"?: Turbo Codes; binary Goppa or  
Viterbi?

And, finally: 5. Which block-cipher mode is "Best"?: CBC w/CTS or Counter-
based CTR?

The answers to these five questions have eluded me. An additional 
consideration is that I'd like to use one of each of the 5 different 
components with Serpent-1 and some compression software (either 777 or 
Malcolm Taylor's RK) - so, the combination might be a factor in your 
responses.

Any help or discussion will, undoubtably be of value. Thank you very much 
in advance.

Respectfully,

Rich Griffin

------------------------------

From: proton <[EMAIL PROTECTED]>
Subject: Re: How to design a new *secure* network protocol from scratch?
Date: Fri, 18 Aug 2000 19:01:21 GMT

> > Now what im trying to figure out is the smartest and most
> > secure way of authenticating each end with eachother and
> > establishing an encrypted session.
> 
>   Why start from scratch?  Is everything else worthless or unsuitable
> for the purpose?

As far as I know, yes.

>   Why not start by reading up on the protocols already designed: such
> as IPsec, TSL, SSH, etc., and go on from there?

The goal is ofcourse to get as much security as possible, but in cases
where a programmer doesnt have the knowledge it must always be possible
to fall back to no encryption.

Personally I want the protocol to be as secure as possible, which is
why im asking here -- Im not an encryption expert.

I've realized the wrongs of my previous idea and I've kinda settled
on public key authentication as default.

I have never implemented any public key algorithms tho, and I would
appreciate pointers to code and other resources to help me out.

/proton

------------------------------

From: Ben Pfaff <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: 18 Aug 2000 15:19:20 -0400
Reply-To: [EMAIL PROTECTED]

"Donald L. Nash" <[EMAIL PROTECTED]> writes:

> In article <8njg8f$no5$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul 
> Schlyter) wrote:
> 
> >Actually, the CDC 6600 had an altneraive character encoding, which
> >used 12 bits ber character.  In CDC jargon, this was called "ASCII",
> 
> Here at UT (where we had a 6600 and a 6400, and then two Cyber 750s by 
> the time I came along), it was called "8-in-12 ASCII" for obvious 
> reasons.

Why wasn't it called 7-in-12 ASCII?

-- 
"Give me a couple of years and a large research grant, 
 and I'll give you a receipt." --Richard Heathfield

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: pRNG, ECC and block modes
Date: Fri, 18 Aug 2000 21:38:01 +0200



Rich wrote:
> 
> Hello group, as a long-time lurker I've learned quite a lot and very much
> appreciate all the discussions. I now have a few questions, which I hope
> you folks can weigh in on. There are as follows:
[snip]

My knowldege is too poor to be able to answer your questions.
But I am afriad you wouldn't get unanimous answers even from
the top dozen professionals. I guess that a lot depends on
your application needs so that 'the best' is probably 
otherwise ill-defined anyway and quite analogous to e.g. the 
best restaurant in town or the prettiest woman in country.
I conjecture that it might be advisable to consult the
standard texts and based on the informations there to make 
one's own (more or less subjective) decision. It is 
apparently not without reasons that the standard texts 
avoid to take position to recommend 'the best', as far as
I am aware.

M. K. Shen

------------------------------

From: "mconroy" <[EMAIL PROTECTED]>
Subject: Intermittent stream cipher?
Date: Fri, 18 Aug 2000 15:37:18 -0400

I would like to know where I might find a cipher algorithm that allows me to
stream plaintext input on an intermittent basis.  The application is logging
messages to a file which must be encrypted.  The file has to remain
encrypted at all times.  However, opening the file, decrypting, adding ONE
line, and reencrypting just doesn't make sense.  I know there are a few
commercial encrypted volume solutions, but I can't believe there isn't an
algorithm out there built to do this sort of thing.  Then again, I'm in
Dilbert-hell and I've only had this assignment for a week.  Using blowfish
and twofish (with mcrypt under RH6.2) I can write one message and decrypt
the file successfully.  However, all subsequent messages decrypt with the
first few bytes mangled.  This happens regardless of the mode I choose.
(which may, in fact, be a problem with mcrypt).  If this isn't the forum for
this type of question, please accept my apologies...and please point me in
the right direction.

Thanks,
Mike Conroy



------------------------------


** 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
******************************

Reply via email to