Cryptography-Digest Digest #133, Volume #11      Wed, 16 Feb 00 11:13:02 EST

Contents:
  Re: UK publishes 'impossible' decryption law (Runu Knips)
  Re: free C crypto API (Runu Knips)
  Re: Which compression is best? (Runu Knips)
  Re: Which compression is best? (Runu Knips)
  Re: decryption (Runu Knips)
  NTRU Speed Claims (100x faster, etc.), explained ([EMAIL PROTECTED])
  Re: Guaranteed Public Key Exchanges (Erik)
  Re: Does RSA use real prime ? (Tom Dunigan)
  Using virtually any cipher as public key system? (Mikko Lehtisalo)
  Re: Using virtually any cipher as public key system? (fvw)
  Hardware crypto device ([EMAIL PROTECTED])
  Academic jobs offered in cryptology and/or computer security (Ross Anderson)
  Re: OTP practical implementation (Anthony Stephen Szopa)
  Re: NIST, AES at RSA conference (Bo D�mstedt)
  Re: NIST, AES at RSA conference (Bo D�mstedt)
  Re: question about PKI... (Bo D�mstedt)

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

From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
Date: Wed, 16 Feb 2000 13:21:52 +0100

Arturo wrote:
> On 16 Feb 2000 01:31:16 GMT, [EMAIL PROTECTED] (Mike Eisler) wrote:
> >In article <[EMAIL PROTECTED]>,
> >Bruce Stephens  <[EMAIL PROTECTED]> wrote:
> >>the police *do* need to prove
> >>something: they need to show that I did have the key.  i.e., it would
> >>not (under the current proposal) be a crime not to decrypt encrypted
> >>material when suitably told to do so unless the police could show that
> >>you once had the key.
> >^^^^^^^^^^^^^^^^^^^^
> >What if the accused has forgotten the key. Or mislaid the container of
> >the key?
>
>         According to the law, you get two years� paid vacion, courtesy of
> Her Majesty�s prisons.  And if you happen to tell anybody about it, you get
> a five-year bonus.

Yes, thats the reason why english police is called the politest of
europe (or even the whole world). You are not put into prison,
you're just on vacation. Sad I'm not living in the kingdom...

This law is idiotic. Why has anyone the right to read some data
when, for example, they are my diary, or my poems ? I've the
right to have some secrets ! And I've the right to store them
electronically, if I want.

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

From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: free C crypto API
Date: Wed, 16 Feb 2000 13:29:42 +0100

!Tom St Denis wrote:
!> In article <[EMAIL PROTECTED]>,
!>   Runu Knips <[EMAIL PROTECTED]> wrote:
!> > Tom St Denis wrote:
!> > > In article <[EMAIL PROTECTED]>,
!> > >  Runu Knips <[EMAIL PROTECTED]> wrote:
!> > > > Tom St Denis schrieb:
!> > > > > In article <862jhk$ohd$[EMAIL PROTECTED]>,
!> > > > >   Greg <[EMAIL PROTECTED]> wrote:
!> > > > > > > Well I decided to release CB a bit early.  I am looking
for
!> > > > > > > comments/suggestions/improvements.
!> > > > > > > Basically CB is a complete crypto API.  It can make/use
RSA
!> crypto,
!> > > > > > > symmetric crypto, has data compression, a RNG, base64
!> routines and
!> > > > > > > more. [...]
!> > > > > > > All of this is free!!!
!> > > > > >
!> > > > > > I downloaded a copy of your stuff and noticed that you did
not
!> > > > > > ask me anything.  Where is the server located?
!> > > > >
!> > > > > I will not dignify that.  I was hoping for real discussion
about
!> > > > > working on CB [i.e bugs or what have not].  This group has
some
!> of
!> > > the
!> > > > > smartest people in the world yet they can't stay on task.
!> > > > > Did you have any troubles building CB on your computer?
!> > > >
!> > > > No problems with VC++ 5.0 under Windows. Will check gcc/linux
at
!> > > > home. And I've seen worser cryptographical libaries before.
!> > > > However, many of this stuff is from other people, plus, for
!> > > > example, IDEA is patented and can't be used for free. But has
!> > > > a twofish implementation, too. Very good, so I can drop IDEA
!> > > > anyway :)
!> > > >
!> > > I am glad you like it.  Please note that the current version up
!> there
!> > > has some bugs in it.  Small glitches... I have been working on it
!> > > locally and plan to upload it again soon.  In the mean time you
can
!> > > still look at it and play around.
!> > >
!> > > [EMAIL PROTECTED]
!> >
!> > Where easy to compile this stuff under Linux. Had to strip
!> > CR, create an unix makefile and remove 3 includes in idea.h.
!> 
!> Cool, if you can send me the unix makefile I will include it in the
!> next release. I have this week off so I want to touch it up.  I have
!> been meaning todo this for a bit.

OOops, I don't have it at hand, but Unix Makefiles are easy:

______________________________________________

default: all

CC=gcc
CFLAGS=-O3 -fomit-frame-pointer -funroll-loops -DNDEBUG
AR=ar
ARFLAGS=r
RM=/bin/rm -f

OBJS=idea.o <... add all object files as ".o" ...>
LIB=libcryptobag.a

all: ${LIB}

${LIB}: ${OBJS}
        ${AR} ${ARFLAGS} $@ ${OBJS}

clean:
        ${RM} ${OBJS}

distclean: clean
        ${RM} ${LIB}

idea.o: idea.c idea.h <... add all include files included by idea.c ...>
<... the same for all other object files ...>
______________________________________________

Just replace the <... ...> comments with what's described there. Hmm
I've
to get the libary from home. THe main problem was, there was already a
"makefile", but it was from dos or windows.

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

From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Date: Wed, 16 Feb 2000 13:42:54 +0100

Tim Tyler wrote:
!> Runu Knips <[EMAIL PROTECTED]> wrote:
!> : Tim Tyler wrote:
!> :> Runu Knips <[EMAIL PROTECTED]> wrote:
!> :> : > Now I've got 2 questions about this:
!> :> : > 1) From a security perspective, how important is compression?
!> :> : If you compress your data before encrypting, the encrypted data
has
!> :> : a known structure which can, for example, be easier tested in a
!> :> : brute-force attack, and maybe helps the decrypter in other
attacks,
!> :> : too.
!> :> Totally the reverse should apply.  This is the primary point in
!> :> compressing in the first place.  The resulting file has /greater/
!> :> entropy-per bit, and thus more closely approaches a random file.
!> : Try writing a test if some byte sequence is some reasonable text
!> : of unknown structure.
!> : Then write a test if some byte sequence is compressed data.
!> : The second program is MUCH simpler, MUCH faster and its results
!> : will ALWAYS be correct.
!> 
!> You don't seem to have this correct.
!> I'm not even sure it makes sense to try to write "a test if some byte
!> sequence is some reasonable text of unknown structure".
!> If the structure of the text is unknown, how can you test for it?

With unknown structure I mean: it does follow only very vague
rules. It may be english text, for example.

!> : Compression adds a KNOWN and FIXED structure which makes attacks
!> : easier, not harder.
!> 
!> This is a description of many crap compressors.

Wrong. This is how ALL compressors work. No matter if simple RLE or
Huffman or ZiffDavis or whatever. Their output always follows rules.

!> You don't show any signs of having followed the compression
discussions
!> in this forum.

Oh, you are the only people in the world which know about cryptology
and compression? Interesting. No, I of course read this in books about
cryptology.

!> Compressors exist that add absolutely zero bits of information to the
!> files they compress.  That represents an absence of added structure
!> - and since the files are shorter, they're rather likely to have less
!> "KNOWN" and "FIXED" structure than the original texts.
!> It's still /possible/ that such compressors will have small areas of
!> concentrated, patterned information, that's easier to target than an
!> equivalent section of the original plaintext - but the better the
!> compression ratio, the less likely this is - since the shorter the
files
!> are the greater the entropy-per-bit and the closer they become to
!> apparently random sequences.

Nope, you can always decompress and check against the first set
of rules. In a simple brute force attack, this would make the
attack somewhat slower, but only by some small and fixed factor.
You see, that is the simple problem like in the enigma - many
of the "improvements" of this machine actually helped the enemy
to break the enigma code.

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

From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Date: Wed, 16 Feb 2000 13:48:06 +0100

wtshaw schrieb:
> 
> In article <[EMAIL PROTECTED]>, Runu Knips
> <[EMAIL PROTECTED]> wrote:
> >
> > Compression adds a KNOWN and FIXED structure which makes attacks
> > easier, not harder.
> 
> Ah...the problem is that larger redundant structures are so much easier to
> spot then smaller; just when does a pile of bricks begin looking like a
> house? Compression algorithms are like other collections of algorithms,
> probably too varied to make pat statements stand except for the few that
> seem to support such a statement.  The key to the debate error in logic on
> them is when you have to cull those that do not support your view in order
> to justify your view.

A cipher which is not secure without compression will not become more
secure when you compress the data. You only do a simple transformation
of the input, which in itself is not hard to "guess" (as a rule, that
transformation is know), and follows fixed rules. So how could that
add any real security ? Except of course that you fight against the
same problem that is handled with CBC.

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

From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: decryption
Date: Wed, 16 Feb 2000 14:00:38 +0100

Pereira schrieb:
> 
> Hi I need some help!  I have a cryptology course and I have no clue what
> I'm doing.  Can someone help me decrypt this message!
> 
> pegarvlywieeijbagfacmoxzcwwdqrizwzsmtibtintseupcuzvpxytfvxmetuifespjmeiikzkqw
> sxktagbtiizhwaratfrhvmmwztiktirevzmrupcwfpvhjeavbiyizqrcpwflvgfxfmfcjnnxcdtsqvn
> lnjuxcdtsqvtddizhwaratfrhveiawaratfrhvkaqrgvxmvkdwizinlrdqswpgxxmtpkqarjtidugv
> eiwhmutiaflrigzazzsveqfspjmpzvgjqarjdwibtcxtifmfcjqzxyxjkmwvqfbtfzicwoovgrvpjcp
> jpnejtrzqseazvqhrirjmwvhznkslsfvfqzcubtekjjmdwjtvjmretiipwnwvvflvnlaqcfjinavdhsw
> fljtidugvhrzqechfndivbrsurxiymmtggfiolgtinqgkufzagtpjqarralaqvjifoqxixuwrxytrlecfjyih
> ikdgikjfgkpqwvgmqoirnvidjfgsqfpfrbmdwggfnqwjxfvmpgptsmkvpelmqfckprsiucielspj
> metitdqqvggfodedpjeuxypegiisqraqhjtkcbxzbvqeyeqvifesavjaxyhzbqwctkcehvuzvqay
> pkqzjfgdifmfc

ee... ww... mm... gg...

This looks like a simple mapping from character to another character,
without
destruction of the underlying structure of the original text.

Just test the count of every character and try to replace it with
another, i.e.
try to replace the most often occuring one with 'e' or 'a' etc.

No, I've no time to do it for you :*)

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

From: [EMAIL PROTECTED]
Subject: NTRU Speed Claims (100x faster, etc.), explained
Date: 16 Feb 2000 13:05:57 GMT


Hi all,

NTRU has posted an update to our FAQ which explains how our speed
claims were derived.  Please take a look at 
http://www.ntru.com/tech.learning.faq.htm#Why is NTRU fast
(there is a link from the main page - www.ntru.com - at the bottom 
of the page) if you are interested.

Thanks -

Daniel Lieman


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

From: Erik <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Wed, 16 Feb 2000 09:03:47 -0500

No Brainer wrote:
> 
> Erik,
> 
> On Fri, 11 Feb 2000 08:21:49 -0500, Erik <[EMAIL PROTECTED]> wrote:
> 
> <snip>
> 
> > There are several approaches:
> >
> > 1) The public keys are signed by a trusted third party's private key,
> > and downloaded from him.
> 
> Can this be made MITM proof?

It can only MITM proof insofar as the the third party and his public key
are trusted.  If this is widely known and distributed, so that you can
verify it from various sources, or if it's built in to distributed
software, then it would be pretty hard for a MITM.

Erik

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

From: Tom Dunigan <[EMAIL PROTECTED]>
Subject: Re: Does RSA use real prime ?
Date: Wed, 16 Feb 2000 09:22:00 -0500

Tom St Denis wrote:

> In article <86kpkd$nq1$[EMAIL PROTECTED]>,
>   Greg <[EMAIL PROTECTED]> wrote:
> >
> > > So I repeat.  If p or q are not prime, encryption/decryption will
> not
> > > work for the most part [it may work once with a slight possibility].
> > > So you must find new primes.
> >
> > So are you saying that all one has to do is randomly select a p
> > and a q and try to encrypt and then decrypt some random data say
> > a half dozen times and if it works well, then p & q are useable?
>
> i am saying: pick two primes and multiply them together.
>
> > I have never heard of this relationship you are describing before.
>
> It's called math you should try it.
>
> If p and/or q is/are not prime then the inverse key 'd' (of 'e') modulo
> (p - 1)(q - 1) will not decrypt when you use it.
>
> So you can be reasonably sure that if the two numbers are not prime
> that encryption can't work.
>
> By deduction PGP does work, therefore with a very high probabilty the
> keys moduli are the result of two primes being multiplied together.
>
> I suggest you study the Pohlig-Hellman cipher.  It works like this.
>
> 1.  Pick a 'p' which is a large prime.
> 2.  Pick a random 'e' which is relatively prime to 'p - 1'
> 3.  Pick 'd' such that 'de = 1 mod (p - 1)'.
>
> To encrypt just do C = M^e mod p
> To decrypt just do M = C^d mod p.
>
> The order of the group [the higest power possible] for a prime modulus
> is the prime minus one.  In this case p-1.  Therefore your numbers must
> merely be multiplicative inverses modulo p-1.  If you can't see it try
> this.
>
> M = M^d^e mod p
> M = M^de mod p
> M = M^1 mod p
> M = M
>
> Try it in the set of real numbers using
>
> e = some integer
> d = 1/e
>
> Like e=5, d=1/5
>
> M = 20
> C = M^5 = 3200000
> M = C^1/5 = 20
>
> Now try it where d is not the multiplicative inverse... say d = 1/3
>
> M = C^1/3 = ~147.36...
>
> Ooops.. doesn't quite work.
>
> anyways... nuff of me.  There is more theory behind it.  But I am
> a 'uneducated type' so that's it for me.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

If p and q are not prime, it is possible for encrypt/decrypt to work.

an example of the following type appears in
Salomaa's textbook, showing that there are other cases where
decryption will succeed.

Consider the case p=p1*p2 where p1 != p2 are primes distinct from q
(and N=pq).  If lcm(p1-1,p2-1,q-1) | (p-1)(q-1), then decryption with
d obtained from ed = 1 (mod (p-1)(q-1)) will succeed.

The case p=15 and q=7 is an example (and N=pq is not Carmichael).


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

From: [EMAIL PROTECTED] (Mikko Lehtisalo)
Subject: Using virtually any cipher as public key system?
Date: Wed, 16 Feb 2000 14:25:28 GMT

I read a long time ago some book and in it was the instructions how to
use any algorithm (for instance des) as a public key system.. It
involved something like creating two keys and ciphering random data
and moving it blahblah.. Can't even remember what the technique is
called :( Any info?


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

From: [EMAIL PROTECTED] (fvw)
Subject: Re: Using virtually any cipher as public key system?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 16 Feb 2000 14:51:04 GMT

In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>I read a long time ago some book and in it was the instructions how to
>use any algorithm (for instance des) as a public key system.. It
>involved something like creating two keys and ciphering random data
>and moving it blahblah.. Can't even remember what the technique is
>called :( Any info?

I don't recall where I read about this, or what it's called, but there
was a way that you take a large amount of random keys. Then you add
a unique ID to each of the keys. Then you encrypt all the key/ID pairs with
a cypher that'll take a few secs on the recipients computer to crack.
The recipient then picks one random encrypted Key/ID pair, cracks it, and
sends you the ID. You then both know what key to use. An attacker however,
would have to brute-force on average half of all the Key/ID pairs, and if
you have a sufficiently large number of them, this becomes unviable.

-- 

                        Frank v Waveren
                        [EMAIL PROTECTED]
                        ICQ# 10074100

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

From: [EMAIL PROTECTED]
Subject: Hardware crypto device
Date: Wed, 16 Feb 2000 16:14:20 +0100

Can anyone help me with this? (probably)
Where can i find info on PCI / ISA crypto cards?

please reply by mail.

best regards
thomas


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

From: [EMAIL PROTECTED] (Ross Anderson)
Subject: Academic jobs offered in cryptology and/or computer security
Date: 16 Feb 2000 15:25:31 GMT

We are hiring at Cambridge. We've posts for a security
lecturer and for an RA to work on designing smartcard
processors. Fuller details at:

        http://www.cl.cam.ac.uk/DeptInfo/Jobs/

Ross Anderson


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

From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: OTP practical implementation
Date: Wed, 16 Feb 2000 07:41:52 -0800

Dan wrote:
> 
> As a given, assume that I have two identical sets of  n  CD-ROMs each
> containing 650Mb of true random data.  Each CD-ROM also has a unique
> internal and external id.
> 
> Is there any available software, hopefully shareware/freeware, that
> manages the practical use of my random data as an OTP?  Specifically the
> reformatting of the text, encryption/decryption of the text and
> management of the offset within the random data to start the
> encryption/decryption (does the offset information travel with the
> encrypted data as clear text?)?
> 
> Thanks for your time and help.


J. Bravo wants you to believe it would be easy.  Like all 
programming, it is simple.  But it gets very complicated 
very quickly.  It almost sounds like he has my encryption 
software.

Unlike J. Bravo, I will answer your question:  yes, there is such 
encryption software.  Instead of using the "OTPs" generated by the 
software, simply use your own.  You only need to place your OTPs 
in the proper file organization.

Go to:  http://www.ciphile.com

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

From: [EMAIL PROTECTED] (Bo D�mstedt)
Subject: Re: NIST, AES at RSA conference
Reply-To: [EMAIL PROTECTED]
Date: Wed, 16 Feb 2000 16:05:38 GMT

[EMAIL PROTECTED] (Terry Ritter) wrote:
....
>From my view, part of the problem with AES is that it eliminates the
>direct financial advantage for the creation of a good cipher.  That
>does not help generate the industry of cipher design (and related
>analysis tools) that we need.  We need to employ good people to work
>on this all day every day for years, with a corporate memory of their
>intermediate results.  We need teams of experts with substantial
>resources and no other responsibility.  We have to pay for that.  
>
>Terry Ritter   [EMAIL PROTECTED]   http://www.io.com/~ritter/
>Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM

Good point. 

A thing that I find disturbing is that NIST has removed ciphers 
from the list of AES candidates based upon poorly documented
statistical tests. Statistical tests of ciphers yield results that, 
for some ciphers, could be correlated with the cipher
quality/security. Generally, this do not hold. Is the selection of 
the five finalists to some degree based upon arbitrary decisions?

I have seen that there has been a (long?) discussion on the 
properties of concatenated ciphers. This is a very old idea.
I have some material on this subject, to appear on our server soon.

2000-02-16
Bo D�mstedt
Chief Cryptographer
Protego Information AB
http://www.protego.se


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

From: [EMAIL PROTECTED] (Bo D�mstedt)
Subject: Re: NIST, AES at RSA conference
Reply-To: [EMAIL PROTECTED]
Date: Wed, 16 Feb 2000 16:05:39 GMT

"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
>Given a function f() with output confined to a space k,
>given any input (of a value in k) to f() the odds of an
>identical output is at least 1/k for a further reapplication
>of the function f().

Dear Joseph Ashwood. Any cipher implemented with 
ONLY this weakness will win the AES.

>Based on this I assert that there is a limit to the number
>of times a function f() (including any cryptographic
>algorithm) can be applied is K and in the case of a
>cryptographic algorithm of length x the maximum number of
>times that algorithm can be applied without being gaurenteed
>to provide a reduction of strength is 2^x.

Dear Joseph Ashwood. Even if applying the function
f(x); x=x0 n times is identical to applying the function f(x), x=x0 
m times, m<n, what use could you make of that ?
If x=x1 then iterating f(x), x=x1 n times will be identical to
iterating f(x) j times j<n. As the number n != j is varying depending 
on x, at least for some, or even most, functions f(x), how would 
you recover the secret key ? 

There could even be a substantial subset of inputs x such that
m=n or j=n. But how would you find out exacly which subset?

Bo D�mstedt
Chief Cryptographer
Protego Information AB
http://www.protego.se


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

From: [EMAIL PROTECTED] (Bo D�mstedt)
Subject: Re: question about PKI...
Reply-To: [EMAIL PROTECTED]
Date: Wed, 16 Feb 2000 16:05:40 GMT

[EMAIL PROTECTED] (Palmpalmpalm) wrote:

>I would appreciate it if you could kindly let me know how to revoke and how to
>get a new certificate without handling the old private-key.

Using Public Key Infrastructure, expect that you cannot revoke a
certified key. If you want to revoke the keys, use a secret key
infrastructure.

Bo D�mstedt
Chief Cryptographer
Protego Information AB
http://www.protego.se


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


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