Cryptography-Digest Digest #867, Volume #9       Sun, 11 Jul 99 19:13:03 EDT

Contents:
  Re: How Big is a Byte? (was: New Encryption Product!) (Gergo Barany)
  Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day ([EMAIL PROTECTED])
  Re: How Big is a Byte? (was: New Encryption Product!) (Paul Schlyter)
  Re: Electronically Exporting crypto source (legally) ([EMAIL PROTECTED])
  Re: How Big is a Byte? (was: New Encryption Product!) (Paul Schlyter)
  Re: How Big is a Byte? (was: New Encryption Product!) (Paul Schlyter)
  Re: Is Stenography legal? (Jim Dunnett)
  Re: How hard is it to find the key in DES? ([EMAIL PROTECTED])
  Re: Uncrackable? ([EMAIL PROTECTED])
  Re: How hard is it to find the key in DES? (James Pate Williams, Jr.)
  Re: Uncrackable? ([EMAIL PROTECTED])
  Re: How strong would this algorithm be ? ([EMAIL PROTECTED])
  Re: Is it possible to combine brute-force and ciphertext-only in an 
([EMAIL PROTECTED])

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

From: [EMAIL PROTECTED] (Gergo Barany)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 11 Jul 1999 17:51:57 GMT

In article <7mal54$khv$[EMAIL PROTECTED]>, Eric J. Korpela wrote:
>In article <[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:
>>However, AFAIK, that is the *only* place the term byte has ever been used
>>to describe anything other than an (ahem) octet
>
>I believe that the current C standard uses the term byte to mean the minimum
>addressable unit of storage (i.e. the unit of storage in which a "char" will
>fit.)  Number of bits is only specified by lower bound.

The number of bits is specified by the CHAR_BIT macro in limits.h.

Gergo

-- 
Down with categorical imperative!

GU d- s:+ a--- C++>$ UL+++ P>++ L+++ E>++ W+ N++ o? K- w--- !O !M !V
PS+ PE+ Y+ PGP+ t* 5+ X- R>+ tv++ b+>+++ DI+ D+ G>++ e* h! !r !y+

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

Date: Sat, 10 Jul 1999 14:28:50 -0400
From: [EMAIL PROTECTED]
Subject: Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day

Harvey Rook wrote:
> 
> <[EMAIL PROTECTED]> wrote in message
> news:7m35s5$o4s$[EMAIL PROTECTED]...
> > >The bottom line is, I would not feel safer just knowing a OTP was being
> > >used to encrypt my messages.
> >
> > Why do people claim OTP security then if it's not secure?
> >
> > BTW no block cipher or stream cipher can be OTP secure so that's not a
> > realistic goal.
> >
> 
> You don't need a cipher that's OTP secure. A 512 bit key will be secure
> against a quantum computer. ( A quantum computer, wasting 1 electron for
> every 2^256 keys it searches, will consume more energy than is released in
> 10^10 supernovae of our sun) For real security, we need ciphers that are
> hard to screw up.
> 
> The major problem with OTP's is that they are very difficult to
> administrate. There are more ways for a human to screw up an OTP, than there
> are ways to screw up a good block cipher.
> 
> If you look over the history of cryptography, you'll see that secure systems
> are almost always compromised by human error, and poor judgment, and not
> because the opponent could brute force his way though the keyspace.

While your facts and reasoning are valid, I think the conclusion is
weak.  Almost all of the history of cryptography perdates computers. 
Only in the last 50 years have computers been available to
cryptanalysts.  Only in the last 25 years have computers been widely
used for it.  So most of the history your refered to is now not a
reliable indicator for the future.

> 
> So, OTP's advantages don't work well in practice.

Has the hotline switched over to PGPfone?

> 
> For example...
> If you are communicating with an OTP, you need to exchange OTP's over a
> secure chanel. Not only is this a pain in the ass, but it's expensive, and
> time consuming.

How so?  Non-time-critical comm is pretty cheap.

> 
> The first rule of good security is don't write your password down. However
> with an OTP, every party a copy. If any copy is compromised, you lose.

This is not specific to OTP.  ALL ciphers have a key.  If the key is
compromised all messages encoded with the key are compromised. BFD.

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

From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 11 Jul 1999 22:14:40 +0200

In article <7mal54$khv$[EMAIL PROTECTED]>,
Eric J. Korpela <[EMAIL PROTECTED]> wrote:
 
> In article <[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:
>> However, AFAIK, that is the *only* place the term byte has ever been used
>> to describe anything other than an (ahem) octet
> 
> I believe that the current C standard uses the term byte to mean the minimum
> addressable unit of storage (i.e. the unit of storage in which a "char" will
> fit.)
 
Does this mean that a C implementation on the Cray supercomputer
must have 64-bit chars?
 
-- 
================================================================
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

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

Date: Sat, 10 Jul 1999 13:58:13 -0400
From: [EMAIL PROTECTED]
Subject: Re: Electronically Exporting crypto source (legally)

Patrick Juola wrote:
> 
> In article <zloh3.207$[EMAIL PROTECTED]>,
> Dmitri Alperovitch <[EMAIL PROTECTED]> wrote:
> >>So, let's assume that I get caught exporting the following single line :
> >>
> >>        for (i=0;i<BLOCKSIZE;i++)
> >>
> >>The first question the police will ask -- and I hope I have an answer
> >>ready -- is "Why did you export a single line of code?"  If I answer
> >>"I wanted to export code and I thought that if I exported it a line
> >>at a time, it would be legal", then I've *ADMITTED* that I'm trying to
> >>break the regulations, and I really can't make the case that I didn't
> >>have malicious intent, that I didn't know what I was doing, or that I
> >>thought what I was sending was protected speech which I believed I
> >>could export freely.
> >
> >You are forgetting that in this country you are "innocent until provent
> >guilty".  YOU don't have to answer anything that they ask you - it's
> >they that have to prove beyond reasonable doubt that that line contains a
> >able to prove that criminals can somehow use that line of code to perform
> >their dirty deeds.
> 
> I'm not forgetting that at all.  They simply pull up this conversation
> from deja-news, subpoena a couple of my friends to testify about whether
> or not I discussed this plan with them, comb my hard drive for the
> scripts I used to split the software into bite-size pieces, and present
> it all to the judge tied up with a pretty ribbon.  Do you really think
> they'd drop an investigation just because I refused to answer their
> questions?  The mere fact that I didn't offer an alternate suggestion
> as to what I was doing would be enough for a jury to find me guilty.

While I agree with your conclusion re attempted export, the preceeding
statement is completely false.  The jurors are not allowed to consider
your refusal to offer an explanation.  If you offer one, they are
required to consider whether they believe it and may speculate on your
true motives if they do not.  But they cannot do _anything_ with the
fact that you refuse to answer.

If the prosecutor even mentions the fact that you refuse to provide an
explanation it is grounds for the judge to throw out the case.  The
judge is required to instruct the jury to ignore your refusal to explain
yourself, and if he thinks your silence is being used against you, the
case goes.

Any lesser standard would render the 5th amendment meaningless.

> 
> Think of it this way -- if they found me on someone's front porch
> at night with lock picks in my hand, that by itself is enough evidence
> for a jury to convict me of (attempted) burglary on.
> 
>         -kitten

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

From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 11 Jul 1999 22:14:13 +0200

In article <[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:
 
> That reminds me of a letter to Byte magazine, wherein a reader protested
> that the use of the term "byte" to describe a storage unit containing 8
> bits was _incorrect_, because the "official" definition of a byte was
> something that could take between 64 and 100 values.
> 
> Of course, that fellow had been reading the definition of "byte" found in
> Donald E. Knuth's description of the MIX computer, not realizing that it
> was not intended as a general definition of the term.
> 
> However, AFAIK, that is the *only* place the term byte has ever been used
> to describe anything other than an (ahem) octet, and it is arguably
> incorrect (the proper term would be "character", which indeed could be 6
> bits, 8 bits, 16 bits, two digits, or whatever on different computers) as
> the term byte was coined and defined, with a definition that made no
> provision for the term referring to any other quantity of storage...
 
You should read the manuals to some old mainframe computers, e.g. the
DEC-10 where bytes could be 7, 8 or even 9 bits (this was a
word-adressed computed where one word was 36 bits: 7-bit bytes
allowed you to pack 5 bytes into one word: 8-bit and 9-bit bytes only
allowed you to pack 4 bytes into one word), or the CDC-6600 where one
byte could be 6 or 12(!) bits (this too was a word-addressed computer
with one word = 60 bits: 6-bit bytes let you store 10 bytes into each
word but these bytes could not represent lowercase letters or most
control characters.  12-bit bytes let you use the entire ASCII
character set, plus more).  On both these computers there were
standard system utilities for converting text files from one byte
size to another.
 
> in "System/360 Principles of Operation".
> 
> However, I have heard that the term "byte" may have been used earlier than
> this - again to designate 8 bits of storage - in the manuals for the
> STRETCH computer.
> 
> Thus, I'm not sure that the common definition of a byte, as 8 bits the way
> a foot is 12 inches,
 
A foot isn't always 12 inches !!!!!  One exception is the old Swedish
decimal inch, which was 1/10 Swedish foot.  It was introduced in 1855,
and was the only legal measure in Sweden from 1863 until Sweden went
metric in 1889:
 
1 Swedish old inch     = 24.741  mm   (1 foot = 296.892 mm)
1 Swedish decimal inch = 29.6906 mm   (1 foot = 296.906 mm)
1 English inch         = 25.4    mm   (1 foot = 304.8   mm)
 
 
> is necessarily wrong. But I do have to admit that
> some authorities could argue it the other way: since "byte" belonged to a
> family of terms including "halfword" and "word", and since not all
> computers have a word length of 32 bits, by implication a byte is also a
> flexible unit.
 
It's all a matter of definition.  It seens like the non-8-bit bytes
are vanishing though.
 
 
-- 
================================================================
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] (Paul Schlyter)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 11 Jul 1999 22:15:04 +0200

In article <[EMAIL PROTECTED]>,
Gergo Barany <[EMAIL PROTECTED]> wrote:
 
> In article <7mal54$khv$[EMAIL PROTECTED]>, Eric J. Korpela wrote:
>>In article <[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:
>>>However, AFAIK, that is the *only* place the term byte has ever been used
>>>to describe anything other than an (ahem) octet
>>
>>I believe that the current C standard uses the term byte to mean the minimum
>>addressable unit of storage (i.e. the unit of storage in which a "char" will
>>fit.)  Number of bits is only specified by lower bound.
> 
> The number of bits is specified by the CHAR_BIT macro in limits.h.
 
....and ANSI C specifies that a char must be at least 8 bits.  Which
makes C a little hard to implement on architectures having bytes
sizes smaller than 8 bits, e.g. the old CDC 6600, which had 6-bit bytes.
 
-- 
================================================================
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] (Jim Dunnett)
Subject: Re: Is Stenography legal?
Date: Sun, 11 Jul 1999 19:53:48 GMT
Reply-To: Jim Dunnett

On Sun, 11 Jul 1999 10:17:41 GMT, [EMAIL PROTECTED] (Lincoln Yeoh)
wrote:

>If you drive through a red light and no one[1] knows about it, it is still
>illegal in most nations as far as I know. 
>
>Whether or not you may get caught/sentenced is a totally different issue
>from legality.
>

Getting caught is the only illegality.

-- 
Regards, Jim.                | PGP Key: pgpkeys.mit.edu:11371
amadeus%netcomuk.co.uk       | Siol Nan Gaidheal
dynastic%cwcom.net           | Preservation of Scottish Culture:
nordland%lineone.net         | http://www.siol-nan-gaidheal.com

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

From: [EMAIL PROTECTED]
Subject: Re: How hard is it to find the key in DES?
Date: Sun, 11 Jul 1999 21:56:44 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (Keith Reeves) wrote:
> Hi! I have a question about DES, maybe one of you will be able to
> help. Let's say you have the plaintext and the ciphertext, but you
> don't know the key. Can you work it out using the plaintext? How hard
> would it be?
>

You can brute force a DES key in about one day if you happend to have
about 120,000 computers.  You can perform a ciphertext only attack
using about O(2^55) effort (O(2^54) if you count the complemenetation).

It's not impossible but it is still hard for the average joe.  My
suggestion don't use DES unless it's minimal security applications.
Besides there are faster algorithms ...

Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

From: [EMAIL PROTECTED]
Subject: Re: Uncrackable?
Date: Sun, 11 Jul 1999 22:14:08 GMT

<snip>

I cannot believe you wrote such things.  Any FSM is solvable in a
finite amount of time.  Why do you say it's 'infinitely' difficult to
solve?

Using 4-12 char passwords is a really stupid idea.  Most people pick
bad passwords that range about 40 chars (upper case and odd letters
such as 'QZY' are normally not used...) so this is 21 to 63 bit keys.
Not much.

Using three PRNGs in a 'mixing' mode of C = ((P + PRNG1) xor PRNG2) +
PRNG3 is not really strong.  There is a linear equation for the first
bit that holds with p=1, then with this the rest of the carry bits can
be attacked.  With this a divide and conquer attack can get the rest.

Seems to me your are posting snake oil.  I would post a complete
description (if you have one at your site I apologize) of the algorithm
and not rely on source code to show it off.  I would also clean up your
claims...

Anyways my thoughts,
Tom


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: How hard is it to find the key in DES?
Date: Sun, 11 Jul 1999 20:28:10 GMT

On Sun, 11 Jul 1999 18:47:03 GMT, [EMAIL PROTECTED] (Keith
Reeves) wrote:

>Hi! I have a question about DES, maybe one of you will be able to
>help. Let's say you have the plaintext and the ciphertext, but you
>don't know the key. Can you work it out using the plaintext? How hard
>would it be?

With one plaintext-ciphertext pair it would probably take you on order
of 2 ^ 56 / 2 = 2 ^ 55 guesses to find the correct key using a brute-
force attack. Using differential cryptanalysis it takes 2 ^ 47 chosen
plaintexts (see _Applied Cryptography_ by Bruce Schneier second
edition Table 12.14 Differential Cryptanalysis Attacks Against DES
page 289).

==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate


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

From: [EMAIL PROTECTED]
Subject: Re: Uncrackable?
Date: Sun, 11 Jul 1999 22:18:37 GMT


> then diffused in turn with each generators output.  The first using
an XOR, the
> second if present using an ADD, the third if present using another
XOR.  This
> method can then be reversed simply by getting the same seeds from the
password,
> generating the same streams, and XOR'ing with the 3rd, SUB'ing the
2nd and XOR'ing
> with the 1st stream.
>

Note that with this 'diffusion' there is really a low amount of
diffusion occuring.  You are relying on the 'carry' bits propagating
error.  However this runs in one direction and really won't do much.
consider flipping one bit, how many change on the output, aax of 2 new
bits will change.  SAC says that at least n/2 bits must change when one
bit changes.

Also like I said xor-add-xor builds a linear equation for the first bit.

BTW you don't normally have to 'guess' the state of the PRNGs to get
the key.  ORYX was attacked because the attacker can *learn* about the
state. You do not provide protection against learning the state (in
fact no finite or deterministic process can stop you from learning the
state...)

Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

From: [EMAIL PROTECTED]
Subject: Re: How strong would this algorithm be ?
Date: Sun, 11 Jul 1999 21:59:10 GMT

In article <_J4i3.15$[EMAIL PROTECTED]>,
  "Daniel Urquhart" <[EMAIL PROTECTED]> wrote:
> Thanks for all of the advice.  I think that I am going to look over
some
> more papers and then try again.  The main idea of this algorith anyay
was to
> keep away the curious (or determined but stupid).

No prob.  Just remember that you should try to break your own algorithm
first.  when I started I use to post all my algorithm ideas, then I
started to break my own ideas... Sometimes it's frustrating, but mostly
just good ol'fun.

Also make sure you know why your algorithm has problems, don't just
patch it up and re-post it.

Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

From: [EMAIL PROTECTED]
Subject: Re: Is it possible to combine brute-force and ciphertext-only in an
Date: Sun, 11 Jul 1999 22:07:41 GMT


> That's one strong assertion that covers everything, including physical
> phenomena ranging from the macroscopic to the elementary particles
> level.  If you do have conclusive justification for it, I think the
> physics community would be interested.

Are you saying that non-deterministic processes exist?  That's a laugh.

In cryptography 'unpredictable' should have more significance
then 'truly random' or 'random'.  There are many ways to get
statisitically independant outputs from a finite state using a
deterministic process.  These are secure for use but not truly random.

And if you use the 'lava lamp' argument (which many people in my Grade
13 compsci course use) then that's a laugh as well.

> Randomly generated values can have significance assigned to them
because
> of the context in which they appear.  Often a randomly generated value
> has significance not because it is *a* random value, but because it is
> *the* random value that plays a particular role in a particular
> context.  A few examples:

But how to you make 'random' numbers in a computer program?
Maybe 'unpredictable' is a better word.

> 1. The encryption key in a private-key cipher is randomly generated,
but
> the fact that the value is used as an encryption key gives it
> significance (and for that reason may require protection).

The actual key doesn't normally need protection as long as the
algorithm is secure.  The keys should be destroyed after being used and
should be well maintained during their lifetime.

> 3. Although most lotteries are not done this way, but in principle,
the
> drawing (random values generation) can be done in advance and the
> results locked away until the deadline for ticket purchase is past.
> Again, we have a situation in which randomly generated values have
> significance and need protection.

These are not random either.

Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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


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