Cryptography-Digest Digest #946, Volume #13      Tue, 20 Mar 01 02:13:01 EST

Contents:
  Re: Fast and Easy crypt send ("Joseph Ashwood")
  Re: Defining a cryptosystem as "broken" ("Joseph Ashwood")
  Re: a 32-bit block cipher (SCOTT19U.ZIP_GUY)
  Re: NSA in the news on CNN (JUzarek)
  Re: AES encryption speed vs decryption speed ("Scott Fluhrer")
  Re: NSA in the news on CNN (jtnews)
  Am I allowed to put any encryption software of my own creation on my  (jtnews)
  Re: Am I allowed to put any encryption software of my own creation on my  (David 
Schwartz)
  Codes that use *numbers* for keys (Juuichiketajin)
  Re: Am I allowed to put any encryption software of my own creation on my  (jtnews)
  Re: Am I allowed to put any encryption software of my own creation on my  (Dennis 
Ritchie)
  Re: a 32-bit block cipher (Gregory G Rose)
  Re: Idea (Paul Crowley)
  Re: What do we mean when we say a cipher is broken?  (Was Art of    Cryptography) 
(Paul Crowley)
  Re: Crypto in VB3 (Hard)

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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Fast and Easy crypt send
Date: Mon, 19 Mar 2001 17:53:01 -0800

Honestly, I think the first thing you need to do is read about cryptography.

First and foremost. You never specified independent keys, the assumption was
otherwise. Second if you do use random keys for each block it IS a OTP.
Third, I strongly suggest that you not just acquire but read (as opposed to
using it to beat up your brother) a copy of either Handbook of Applied
Cryptography, or Applied Cryptography, preferably both. We can go round and
round and round with any learned person here easily capable of decimating
your ciphers for the next 10 years, or you can take you copy of HAC or AC
and read it thoroughly, feel free to ask questions, but please stop posting
idiotic attempt to make ciphers that are either (A) incomplete, (B) known
for the last century or more, or (C) a Vigenere cipher.
                Joe

"amateur" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The text is encrypted with my algo. Read before attaching.
> The ouput you are looking for is random.
> Every bit is crypted with symbol which is choosen randomly.
> If I choose odd and even to encrypt. Then the number 0 or 2 or 4 or 6 or
> 8 represent the bit 0.
> So the ouput E you are trying to test is random.
> That's what you don't understand.
> I know this type of attack.
> If you use you are going to find millions of output with odds and even.
> Like OTP.
> You could find "hello" or thank or all strings with 5 characters.
>
>
>
> Joseph Ashwood wrote:
> >
> > This looks to be the same algorithm you posted a few days ago (addition
and
> > subtraction are the same operation). Let's see if I remember correctly.
It's
> > a Vigenere cipher (I really suggest you at least look this up before
posting
> > the same drivel again) therefore the attack is:
> > Take 2 blocks add them to each other
> > You have now eliminated the key
> > If it's in English you will have a very small number of valid texts that
> > could come out the other end (1 bit of entropy per character), determine
> > which two add to the given value, decide on order, solve:
> > A-K=E
> > Where the value E is from the supplied stream, A is the now
known-plaintext,
> > K is easily solves. Your entire cipher is (just like it was the last
time
> > you posted it) completely eliminated.
> >                         Joe
> >
> > "amateur" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > [snip hey look at my Vigenere Cipher which I've posted at least twice
now]



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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Defining a cryptosystem as "broken"
Date: Mon, 19 Mar 2001 17:45:47 -0800

It is my belief that the model itself should supply for it's own
re-evaluation timeframe. For some systems it is vital that it be reviewed
continually, for others it may only be necessary that it be reviewed
annually. If the path was dependable, say we know that in 5 years X will
occur and 128-bit Rijndael will not longer be secure, then I would suggest
choosing a decommision date ahead of time, however we don't even know what X
is, let alone when it will happen or even if it will affect Rijndael at all,
so it takes periodic vigilance to determine when the decomminsion date has
arrived.

Based on this a thread/attack model needs to take into account the current
state of the art and a buffer-zone, any erosion into the buffer zone
immediately makes the decomission date immediate or as close to it as
possible. With a solid threat/attack model it is generally possible to
select a replacement cipher or protocol very quickly.
                            Joe

"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Joseph Ashwood wrote:
> >
> > I don't think that one can say flatly, cipher X is broken, cipher Y is
not.
> > We must first built a threat/attack model.
> [snip]
> > Using this threat/atack model as a guideline one can find a suitable
> > encryption algorithm that as close as possible meets the speed
requirements.
>
> I surmise that one problem lies in the fact that one can't
> fix a small number of such models (with correspondingly
> 'fixed' numerical quantities pertaining to them) and apply
> these to given applications, for these could vary in quite
> wide ranges. In other words, there could be sort of
> combinatorial explosion. The bigger problem seems to be,
> though: Given a model and a cipher, how do we assure
> that the 'security' that one computes is correct? Do
> we know all potential techniques of attack? Or do the
> model limit themselves to specific known techniques? I
> conjecture that one has in matter of security of ciphers so
> many 'fuzzy' factors that one can only arrive with quite
> an amount of subjectivity certain 'feeling' of security
> in any concrete case, something in my humble view probably
> very much less sure than e.g. what an engineer has about
> the safety of a bridge that he has built. BTW, would the
> (in some sense rather inexact) manner that the engineers
> often deal with their questions of security be able to
> satisfy the requirements of crypto (purists) at all?
>
> M. K. Shen



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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: a 32-bit block cipher
Date: 20 Mar 2001 02:02:24 GMT

[EMAIL PROTECTED] (Gregory G Rose) wrote in <996cks$[EMAIL PROTECTED]>:

>Recently I needed a way of generating an
>unpredictable permutation function of 32-bit

  If you define it then its not unpredictable.
I think you meant to generate one that appears
to be somewhat random by common methods.

>values, in other words, a block cipher with a
>32-bit block. It was important for that
>application that 32-bit values generated over a
>period of time should not repeat. I searched
>around looking for such a cipher, and couldn't
>find one, not surprisingly since it would be
>insecure in the face of a codebook style attack
>(the entire codebook would fit into 16GB).

  What your looking for is a Single cycle permutaion.
Its not that hard to create one.  

>
>Anyway, that didn't change the fact that I needed
>one, so I wrote one. I took Skipjack (Panu
>Rissanen <[EMAIL PROTECTED]>'s version) and turned it
>into a 24-round feistel cipher. It retains the
>F-table, the G-permutation and the key-schedule
>(including the 80-bit keys), but it loses the
>feedback register structure and the two different
>kinds of rounds.

   The 80 bit key implies that it can't be too randon
because there are ((32**2) - 1)! different single 
cycle transforms and to define them all as in
scout19u would take over a one million byte key
much more than 80 bits.   Also how do you know each key you
used will lead to a maximum cycle length in your
32 bit block?

>
>Then for the fun of it I applied for, and
>received, an export license from the Australian
>Defence Signals Directorate that allows me to post
>it on the Web. It's at:
>  http://www.home.aone.net.au/qualcomm/skip32.c
>
>It's freely available, and I hope it is of use to
>someone else too. If anyone sees any problems with
>it, please do tell me.
>
>Greg.
>




David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
        http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
        http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
        http://radiusnet.net/crypto/  then look for
  sub directory scott after pressing CRYPTO
Scott famous Compression Page
        http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:

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

From: [EMAIL PROTECTED] (JUzarek)
Date: 20 Mar 2001 02:19:40 GMT
Subject: Re: NSA in the news on CNN

CNN will broadcast   a 5-part series on NSA 19-23 March
on the network's 10 pm EST newscast.  Each of the five
segments will be from 3 to 4 minutes long 
 
Mon   The Codebreakers
Tue    Spying on you
Wed  The Codemakers
Thu    The Listener
Fri     The Traitor Problem








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

From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: AES encryption speed vs decryption speed
Date: Mon, 19 Mar 2001 18:47:38 -0800


Brian Gladman <[EMAIL PROTECTED]> wrote in message
news:XBut6.409$Ph.30133@stones...
>
> "Thierry Falissard" <[EMAIL PROTECTED]> wrote in message
> news:995g2b$gpp$[EMAIL PROTECTED]...
> > Unless I am badly mistaken, I have the impression
> > that decryption with AES must be somewhat slower
> > than encryption. Computations in the InvMixColumns
> > transformation should take more time than in MixColumns,
> > because of the matrix that is used for multiplication.
> > Could somebody confirm this ?
>
> For high speed implementations the encryption and decryption operations
are
> about the same in speed terms but key setup for decryption takes a lot
> longer than for encryption.

I assume that by "high speed implementation", you mean hardware.  For
software, once the key schedule has been run, it doesn't really matter which
direction you use the subkeys (except for memory constrained situations
where you can't express the full key schedule at once, which hardly qualify
as "high speed implementations").

>
> Obviously the impact this will have will depend on whether the decryption
> mode of the algorithm is needed and, if it is, how often the keys are
> changed relative to the number of blocks being processed.

Actually, if keys are going to be used in decryption mode, they can be
preprocessed by stepping them into the form they have at the end of the key
schedule.  Then, when performing a decryption, you simply step through the
key schedule backwards, generating the subkeys in the order you use them.
That way, the major pain can be rolled into key setup time, and not
everytime you change keys.  Or, is there something subtle with the AES key
schedule that I missed?

--
poncho




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

From: jtnews <[EMAIL PROTECTED]>
Subject: Re: NSA in the news on CNN
Date: Tue, 20 Mar 2001 02:57:50 GMT

thanks I have my VCR programmed now!


JUzarek wrote:
> 
> CNN will broadcast   a 5-part series on NSA 19-23 March
> on the network's 10 pm EST newscast.  Each of the five
> segments will be from 3 to 4 minutes long
> 
> Mon   The Codebreakers
> Tue    Spying on you
> Wed  The Codemakers
> Thu    The Listener
> Fri     The Traitor Problem

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

From: jtnews <[EMAIL PROTECTED]>
Subject: Am I allowed to put any encryption software of my own creation on my 
Date: Tue, 20 Mar 2001 03:45:38 GMT

Am I allowed to put any encryption 
software of my own creation on
my public ftp site?

Is free software restricted in anyway
by export controls?

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

From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Am I allowed to put any encryption software of my own creation on my 
Date: Mon, 19 Mar 2001 19:52:14 -0800


jtnews wrote:
> 
> Am I allowed to put any encryption
> software of my own creation on
> my public ftp site?

        Is it open source?

> Is free software restricted in anyway
> by export controls?

        Depends upon what you mean by "free software".

        DS

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

From: [EMAIL PROTECTED] (Juuichiketajin)
Subject: Codes that use *numbers* for keys
Date: 20 Mar 2001 04:09:57 GMT

Several months ago, I saw on the Web some sort of code called Manticore. 
I am not 10% sure, but I think it used a PGP-like algorithm. But what I 
like about it more than PGP is that it uses actual *numeric* *numbers* 
for code keys, not weird number / letter / whatever combinations that 
can't be pronounced. Even hiragana would be an improvement, as long as 
they left out Wo and N. (I got this idea from a video game that has 
kana passwords.) You can read off a string of digits or kana, not 
alphabet soup. And if you use digits, they should probably be decimal 
digits. And octal is OK; all octal digits are also decimal. Just mark it 
as octal.
Do you know where I can find Manticore, or some code that uses numeric 
numbers for keys?
Why are key lengths always given in bits? Why not a code that takes, oh 
say, 60 decimal digits for a key? I can relate to 60 digits, not to so 
many bits.


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

From: jtnews <[EMAIL PROTECTED]>
Subject: Re: Am I allowed to put any encryption software of my own creation on my 
Date: Tue, 20 Mar 2001 04:15:08 GMT

David Schwartz wrote:

>         Is it open source?

yes it's all open source.

> 
> > Is free software restricted in anyway
> > by export controls?
> 
>         Depends upon what you mean by "free software".

Free software as defined at
http://www.gnu.org/philosophy/free-sw.html

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

From: Dennis Ritchie <[EMAIL PROTECTED]>
Subject: Re: Am I allowed to put any encryption software of my own creation on my 
Date: Tue, 20 Mar 2001 05:31:59 +0000



jtnews wrote:

> > > Is free software restricted in anyway
> > > by export controls?
> >
> >         Depends upon what you mean by "free software".
> 
> Free software as defined at
> http://www.gnu.org/philosophy/free-sw.html

The FSF's definition of free software is not especially
relevant.  More relevant is the copious material under
 http://www.bxa.doc.gov/Encryption/regs.htm ,
especially the 10/19/00 Federal Register link on the
upper right of the page.  The document is tedious to
read, but rather more liberal in its requirements than
one might expect.  Things have changed.

        Dennis

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

From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: a 32-bit block cipher
Date: 19 Mar 2001 22:11:36 -0800

In article <[EMAIL PROTECTED]>,
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Gregory G Rose) wrote in <996cks$[EMAIL PROTECTED]>:
>
>>Recently I needed a way of generating an
>>unpredictable permutation function of 32-bit
>
>  If you define it then its not unpredictable.
>I think you meant to generate one that appears
>to be somewhat random by common methods.

Unpredictable to an attacker who doesn't know the
key.

>  What your looking for is a Single cycle permutaion.
>Its not that hard to create one.  

Yes, but I don't need it to be a single cycle
permutation in the sense I think you mean... it
will just run in counter mode. At time "t" I
represent t in 32 bits, encrypt it, and use that
value.

>   The 80 bit key implies that it can't be too randon
>because there are ((32**2) - 1)! different single 
>cycle transforms and to define them all as in
>scout19u would take over a one million byte key
>much more than 80 bits.   Also how do you know each key you
>used will lead to a maximum cycle length in your
>32 bit block?

An 80 bit key is plenty for my application, and I
didn't want to change Skipjack more than was
needed... mucking with key schedules is very
sensitive stuff.

Since it is a reversible encryption algorithm, by
definition each counter value input to it is
distinct, each output value will also be
distinct. After 2^32 outputs, the outputs will
form a single-cycle permutation, yes... but not
one definined directly by the encryption function.

Greg.
-- 
Greg Rose                                       INTERNET: [EMAIL PROTECTED]
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/ 
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

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

Subject: Re: Idea
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Tue, 20 Mar 2001 06:32:19 GMT

[EMAIL PROTECTED] (John Savard) writes:

> On 18 Mar 2001 19:50:25 GMT, [EMAIL PROTECTED]
> (SCOTT19U.ZIP_GUY) wrote, in part:
> 
> >Of couse the pompous assholes will find fault with many
> >of so called ametur stuff and use that as an excuse to never really
> >check what many ametures are doing.
> 
> Given the number of hours in the day, and the fact that as far as most
> amateur stuff is concerned, the time of the 'pompous' ones is better
> spent for them working on their own stuff than looking at that, they
> need _some_ excuse.

Actually the professionals will look at amateur cryptosystems, and
even accept them as papers to conferences, if you can present them
properly and argue their advantages in the right way.  I know, because
I did it.

I was in every way an amateur - I had a largely unrelated day job to
do and had to work on the paper in my free time, I'd only ever bought
two books about crypto (Applied Crypto 1st ed and 2nd FSE proceedings)
downloading everything else, my only qualification was a 2:2 in
Computer Science, and I'd never met anyone on the program committee or
had any kind of "friend of a friend" recommendation - anyone who *did*
know me, knew me through my participation in this very newsgroup.  But
I wrote up my cipher as best I could, submitted it to a conference,
got it rejected with reviewer's comments, worked on it some more using
the comments to direct me, submitted it again, and got accepted; I did
the first presentation of my life in front of a crowd including quite
a few crypto demogods presenting my cipher at Fast Software Encryption
2000 in New York.

Now I'm a professional cryptographer.  I am living proof that this
idea of a "cryptographer's closed shop" is nonsense.  Scott's ideas
are ignored, not because he's an amateur, but because:

- they are presented very badly in every way
- they actually don't have the merit to warrant more attention.

And that's it.
-- 
  __  Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/

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

Subject: Re: What do we mean when we say a cipher is broken?  (Was Art of    
Cryptography)
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Tue, 20 Mar 2001 06:32:19 GMT

"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:

> Paul Crowley wrote:
> > ...  The attacker doesn't have to recover plaintext; they just
> > have to demonstrate that it's not like an "ideal" component of its
> > type.  Stream ciphers are a good example here: if there's a cheaper
> > way than brute force of detecting that the stream cipher is in use at
> > all, that's a problem.
> 
> I have to disagree.  That would be the case for *steganography*,
> but not for encryption.  In general it is *obvious* when encryption
> is being used, and if the adversary cannot recover any of the
> hidden information then he cannot be said to have broken the system.

Perhaps I mis-stated.  Let me put it another way: a cryptographic
pseudo-random number generator (often used to build a Vernam stream
cipher) if there's a cheaper way than brute force for an attacker to
distinguish the pseudo-random stream from a truly random stream.  This
is a good property because any way of recovering information from the
Vernam-encrypted stream gives you a distinguisher for the CPRNG, so if
the CPRNG is distinguisher-free for a particular computational bound
then the encryption is "perfect" in some sense.  Contrariwise, any
distinguisher for the CPRNG allows an attacker to distinguish the "all
zeroes" plaintext from a perfectly random plaintext, and therefore
leaks information about the plaintext.
-- 
  __  Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/

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

From: [EMAIL PROTECTED] (Hard)
Subject: Re: Crypto in VB3
Date: Tue, 20 Mar 2001 07:08:54 GMT

On Mon, 19 Mar 2001 15:56:10 -0500, "Ryan M. McConahy"
<[EMAIL PROTECTED]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>
>To: sci.crypt
>Subject: Crypto in VB3
>
>Does anyone know of any libraries/DLLs/source code that I could use
>in Visual Basic 3?
>
>Thanks in advance.
>
>Ryan M. McConahy
>
>-----BEGIN PGP SIGNATURE-----
>iQA/AwUBOrZyMqFn8yalvjU2EQLmbgCfQjFk8V8ezHINCRlShQQCofcWFpwAmwQZ
>2B/fTUpE3E7T6isFRQmGNo31
>=1vLJ
>-----END PGP SIGNATURE-----
>

Go here: http://zarr.net/vb/download/encryption.asp

This code is for 32-bit VB, but you may be able to get it to work in
VB3 by keeping track of variables (long is 16-bit in VB3 but is 32-bit
in current versions, etc.)

The MD5 code is questionable (didn't pass vector tests) but the SHA-1
and the RC4 are good (pass vector tests), although slow.  The mime
(base64) encoding and decoding also works well.

There are also modules for CRC calc, LZW compression of strings,
Gost2, and SkipJack encryption, although I haven't tested them.

All in all, it is a fairly fun package for horsing around in VB.

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


** 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 by posting to sci.crypt.

End of Cryptography-Digest Digest
******************************

Reply via email to