Cryptography-Digest Digest #87, Volume #13 Fri, 3 Nov 00 18:13:00 EST
Contents:
Re: Rijndael Security (SCOTT19U.ZIP_GUY)
Re: srp-1.7.0 released w/TLS Telnet security, X11 forwarding support (Michael
Erskine)
Re: Visual Basic (Ichinin)
Re: Microsoft's script encoder ("Lefty Louther")
Re: Hardware RNGs ([EMAIL PROTECTED])
Re: Crypto Export Restrictions (Scott Craver)
Re: Microsoft's script encoder (Simon Johnson)
Re: Microsoft's script encoder ("Lefty Louther")
Re: Calculating the redudancy of english? (JPeschel)
Re: how i decode this? ("David C. Barber")
Re: Calculating the redudancy of english? ("Kristopher Johnson")
Crypto++ 4.0 released, and updated crypto benchmarks (Wei Dai)
Re: Q: Computations in a Galois Field (Mok-Kong Shen)
Re: Q: Computations in a Galois Field (Mok-Kong Shen)
example code for your use (Kenneth Lantrip)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Rijndael Security
Date: 3 Nov 2000 19:08:17 GMT
[EMAIL PROTECTED] (ajd) wrote in
<3a028dcf$[EMAIL PROTECTED]>:
>
>How secure is Rijndael when given (most of) the plaintext and the cipher
>text? For example if I encrypt a bitmap (and somehow the interceptor
>knows its a bitmap), the interceptor then knows that the first block
>will decrypt to
>
>42 4D ** ** ** ** 00 00 00 00 36 00 00 00 28 00
>
>where bytes 0-1 are the bitmap identifier
>2-5 are the file size (which the interceptor doesn't *quite* know as my
>encrypted file will be a multiple of the block size, and vthe plaintext
>file may not be)
>6-9 reserved and always zero
>10-13 is the offset to beginning of bitmap data
>14-17 is th header size
>
>Given this information about the plaintext, and given the encrypted
>text, can the interceptor work out the key? It seems to me like we are
>giving away a bit too much information. Is there a standard to get
>around this problem?
>
>regards
>andrew
>
>
I agree with you especailly if the attacker knows what kind of file
your sending. There are many ways to get a round this problem you could
use MAtts BICOM he takes exactly this kind of header problem in to
condsideration. Since after the compression phase the first 20 K of the
file is whitetened then the CBC mode of Rijndael occurs. Or you
could use compress and use a all or nothing encryption pass like
scott16u to whiten the whole file compressed or not compressed and
then use the blessed AES method supplied in Matts code. THe advantage
of the second is that even a one bit change in the input file changes
the whole file. No matter how long it is.
But if you follow so called experts which may not really care if
your stuff is safe. THey will either give a none bijectiv method
or say same crap that modern ciphers are to hard to break so don't
worry about it.
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: Michael Erskine <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix,comp.os.linux.security
Subject: Re: srp-1.7.0 released w/TLS Telnet security, X11 forwarding support
Date: Fri, 03 Nov 2000 14:25:38 -0500
Thomas Wu wrote:
Thomas, thank you.
--
Watch your thoughts; they become words.
Watch your words; they become actions.
Watch your actions; they become habits. -- Frank Outlaw
Watch your habits; they become character.
Watch your character; it becomes your destiny.
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Visual Basic
Date: Fri, 03 Nov 2000 07:24:28 +0100
Patterson Programming wrote:
> Ichinin, your syntax uses a 'variant' data type. There is a risk that VB
> would move/copy the data in dynamic memory. That makes 'burning' the key
> material unreliable. I prefer to use static numeric arrays for such
> purposes.
Perhaps, but have you tried it?
You could even try:
Stuff = Array("1", "2", "3", ... , "N")
For X...next
Value = Cint(Stuff(X))
Next X
> Also, performance is at least as high using my implementation.
Yes, but some people are concerned with the _layout_ of your
implementation, after all - the layout of your code is sooooo
much more important than actual performance, isn't it? :o)
(yes, irony is the word of the day...)
Regards,
Ichinin
------------------------------
From: "Lefty Louther" <[EMAIL PROTECTED]>
Subject: Re: Microsoft's script encoder
Date: Fri, 3 Nov 2000 21:28:26 +0200
I don't think it's a byte code because you can convert any text you like via
screnc.exe not only code.
Lefty
>
> It most likely is not an encryption algorithm, perhaps it's a byte code
> (like java) stored using ASCII chars...
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Hardware RNGs
Date: Fri, 03 Nov 2000 19:18:57 GMT
> No, of course not. However, at least it doesn't *reduce* entropy
Actually I will differ with you there, you seem to be making the common
mistake of assuming that SHA-(whatever) offers perfect entropy
consolidation, we have no such proof, and my belief at least is to the
contrary. To test my theory of non-perfect entropy reduction would be
compute intensive or human intensive, but I believe that if you take a
start value, feed that into the hash function, feed the result into the
hash function, etc. I believe you will find a loop sooner than full
exhaustion (2^256 for SHA-256). This reveals non-perfect entropy
because it reveals that from that start value, the nth value in the
chain can be guessed with probably higher than 1/{output space} without
computing the value.
Granted the space will be enormous, for SHA-256 I'd expect the length
of that loop to be somewhere on the order of 2^200+ values in length,
but I don't expect it to be perfect.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: 3 Nov 2000 20:22:43 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
>If you don't get it from reading the Help files you need to learn
>how to read. Many many people have read the Help files and ran
>the software and are using the software and they understand it all
>perfectly well.
We're not talking about how to _use_ the software, but
the specific algorithm it is based on.
If you want people to analyze your PRNG, output source
code or good pseudocode (no steps missing, no ambiguous
bits) for the PRNG part of the software.
>If you have some valid criticism of the software post it and support
>your position with facts.
Valid criticism: you won't provide a sufficiently readable
description of your algorithm.
Why don't you just _look_ at the way real PRNGs are described
in _Applied Cryptography_? Diagrams and source code are
provided which explain them unambiguously. People will use
them, rather than your system.
Valid criticism #2: a program requiring a user to futz around
(w/ a deck of cards, say) for fifteen minutes to generate a
crypto key is like a TV requiring a user to mess with a slide
rule for 15 minutes in order to change a channel.
Valid criticism #3: before people on sci.crypt corrected you,
you were calling your program a One-Time-Pad (which it is not.)
I suspect that if people on this group weren't here to keep you
honest, you'd have made all sorts of false claims about your
system.
>So far you are just a whiner who does not do his homework.
Speaking of homework, let me know if you want some good
exercises on permutation groups. It is math, you know.
-S
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Microsoft's script encoder
Date: Fri, 03 Nov 2000 20:27:47 GMT
In article <8tv1oj$iv$[EMAIL PROTECTED]>,
"Lefty Louther" <[EMAIL PROTECTED]> wrote:
> Can you please be more specific ?
>
> Thank you,
> Lefty
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:8tv05b$n87$[EMAIL PROTECTED]...
> > In article <8turns$qbe$[EMAIL PROTECTED]>,
> > "Lefty Louther" <[EMAIL PROTECTED]> wrote:
> > > When i use microsoft's script encoder (screnc.exe) for
> > > string :
> > > response.write ("lakis")
> > > I get :
> > > #@~^IAAAAA==@#@&DnkwKx/?RS.kD+~`rVCVb/J*@#@&vwgAAA==^#~@
> > >
> > > Does anyone know what kind of cipher algorithm is it ?
> >
> > It most likely is not an encryption algorithm, perhaps it's a byte
code
> > (like java) stored using ASCII chars...
> >
> > Tom
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>
Even if its an encryption algorithm, its pants. Look at the cipher-text
expansion :P
Hrm, 'AAAAA' - if this was generated randomly (which it should look
like it has) then the probability of this occuring would be one in
around a trillion. On the same line, 'A' is repeated three times
aswell, which has its own probability of occurance which is roughly
equal to one in 16 million. On top of this there are loads of pairs of
two identical letters in a string, which has its probability of one in
65536.
This points towards a pretty pathetic cipher, if you think this secure,
think again.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Lefty Louther" <[EMAIL PROTECTED]>
Subject: Re: Microsoft's script encoder
Date: Fri, 3 Nov 2000 22:47:33 +0200
No i don't think it's secure.Microsoft sais that it's unsecure.
I think the first part is part of the checksum.
When i encode different data i get the same AAAAA.
It's not an encryption, it's an encoding.
I want to learn how it works.
If you have any idea please help me.
Thanks,
Lefty
"Simon Johnson" <[EMAIL PROTECTED]> wrote in message
news:8tv73q$trj$[EMAIL PROTECTED]...
> In article <8tv1oj$iv$[EMAIL PROTECTED]>,
> "Lefty Louther" <[EMAIL PROTECTED]> wrote:
> > Can you please be more specific ?
> >
> > Thank you,
> > Lefty
> >
> > "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> > news:8tv05b$n87$[EMAIL PROTECTED]...
> > > In article <8turns$qbe$[EMAIL PROTECTED]>,
> > > "Lefty Louther" <[EMAIL PROTECTED]> wrote:
> > > > When i use microsoft's script encoder (screnc.exe) for
> > > > string :
> > > > response.write ("lakis")
> > > > I get :
> > > > #@~^IAAAAA==@#@&DnkwKx/?RS.kD+~`rVCVb/J*@#@&vwgAAA==^#~@
> > > >
> > > > Does anyone know what kind of cipher algorithm is it ?
> > >
> > > It most likely is not an encryption algorithm, perhaps it's a byte
> code
> > > (like java) stored using ASCII chars...
> > >
> > > Tom
> > >
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> >
> >
> Even if its an encryption algorithm, its pants. Look at the cipher-text
> expansion :P
>
> Hrm, 'AAAAA' - if this was generated randomly (which it should look
> like it has) then the probability of this occuring would be one in
> around a trillion. On the same line, 'A' is repeated three times
> aswell, which has its own probability of occurance which is roughly
> equal to one in 16 million. On top of this there are loads of pairs of
> two identical letters in a string, which has its probability of one in
> 65536.
>
> This points towards a pretty pathetic cipher, if you think this secure,
> think again.
>
>
> --
> Hi, i'm the signuture virus,
> help me spread by copying me into Signiture File
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Calculating the redudancy of english?
Date: 03 Nov 2000 20:48:55 GMT
Douglas A. Gwyn writes:
>JPeschel wrote:
>> Simon Johnson [EMAIL PROTECTED] writes:
>> >How does one calculate the redudancy of english?
>> Use the index of coincidence.
>
>No.
>
>For a correct answer see Shannon's paper.
Oops.
Thanks, Doug.
I think this is the applicable paragraph by Shannon.
"The ratio of the entropy of a source to the maximum
value it could have while still restricted to the same
symbols will be called its relative entropy.
This is the maximum compression possible when we
encode into the same alphabet. One minus the relative
entropy is the redundancy. The redundancy of ordinary English,
not considering statistical structure over greater
distances than about eight letters, is roughly 50%.
This means that when we write English half of what we
write is determined by the structure of the language and
half is chosen freely. The figure 50% was found by
several independent methods which all gave results in
this neighborhood. One is by calculation of the entropy
of the approximations to English. A second method
is to delete a certain fraction of the letters from a
sample of English text and then let someone attempt to
restore them. If they can be restored when 50% are
deleted the redundancy must be greater than 50%. A
third method depends on certain known results in
cryptography."
I'm off to re-read <i>Finnegan's Wake</i> now. :-)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: how i decode this?
Date: Fri, 3 Nov 2000 13:56:32 -0700
If the lines are 61 characters starting with "M", then it is most likely
uuencoded. In uuencode, the first character is the line length ("M"=60)
with the data following. 60+1 character line lengths are the most common
size.
For more information on uuencode, find a Unix system and type "man
uuencode".
*David Barber*
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Eduardo Hernandez wrote:
> > how i decode or decrypt this kind of messages???
> > MQ'(E<H8.=8"AKS*7C$$KTGXXF_-D:M+&![;'PY61C0<B$-?E1B.^XKPMT,:T
> > MI38V9-JN7+H/[C2^9*R1&X`4;HUTLE$7D4D].B7JPZMTA2Z?;U9,^N$C8_C8
> > ME?!/K?>7ZBM]H\OAPIPI+OR<S>::]>K<ESP$9RULS>)*[[@DAV:#LU\;+:'C
> > MQH#&RZW06I'F7I^>QHD[!(_\_?DPX%&I`Y@NV9MZ!\%JD)8#%&YML5L>VG[6
> > MCL^M[2!5+;[U\[?&[R%KO^T/&=V9,OV6-VI7G`K-Z&<-,.6_$VJZ&[#XE"6`
> > M`:G/;Q3+T]+K8Q3^+KYQGEU-.2@A\IM6_E9Y)+&G!QO<];U:5P4/OC,E$TU]
> > M`*@:H4DZVY?`B!&5%^OL_'O039X;>T[&K/U^7;E"&QPS$[.8R:[R:NI&)>/>
>
> You should discuss it with whoever created the messages.
> Note that these all start with M and use a limited character
> set. Probably it's a base-64 encoding similar to what MIME
> and uuencode use.
------------------------------
From: "Kristopher Johnson" <[EMAIL PROTECTED]>
Subject: Re: Calculating the redudancy of english?
Date: Fri, 03 Nov 2000 21:02:57 GMT
Dictionary entries aren't representative of "real-world" letter or word
frequencies.
-- Kris
"David C. Barber" <[EMAIL PROTECTED]> wrote in message
news:8ts7mu$1ifq$[EMAIL PROTECTED]...
> "Bill Unruh" <[EMAIL PROTECTED]> wrote in message
> news:8tq2bf$2dt$[EMAIL PROTECTED]...
> > In <8tkosd$84d$[EMAIL PROTECTED]> Simon Johnson
<[EMAIL PROTECTED]>
> writes:
> >
> > > How does one calculate the redudancy of english?
> >
> > Then you have to decide, are you going to take a typical passage (in
> > which many words occur far far far more frequently than others) or a
> > dictionary ( where all words occur equally-- once).
>
> What about a Dictionary with definitions (e.g. the Webster available at
> Project Gutenberg)? Would analysis there yield useful data?
>
> *David Barber*
>
>
>
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Crypto++ 4.0 released, and updated crypto benchmarks
Date: Fri, 3 Nov 2000 13:54:56 -0800
[This announcement is cross posted to comp.compression because Crypto++
contains zlib-compatible compression/decompression features.]
Crypto++ 4.0 has just been released. You can find download instructions
for Crypto++ on its home page at http://www.cryptopp.com.
Updated benchmarks are available at
http://www.weidai.com/benchmarks.html.
Crypto++ is a free C++ class library of cryptographic schemes. Changes
made in version 4.0 include:
- added Skipjack, CAST-256, Panama, SHA-2 (SHA-256, SHA-384, and
SHA-512), and XTR-DH
- added a faster variant of Rabin's Information Dispersal Algorithm
(IDA)
- added class wrappers for these operating system features:
- high resolution timers on Windows, Unix, and MacOS
- Berkeley and Windows style sockets
- Windows named pipes
- /dev/random and /dev/urandom on Linux and FreeBSD
- Microsoft's CryptGenRandom on Windows
- added support for SEC 1 elliptic curve key format and compressed
points
- added support for X.509 public key format (subjectPublicKeyInfo) for
RSA, DSA, and elliptic curves
- added support for DER and OpenPGP signature format for DSA
- added support for ZLIB compressed data format (RFC 1950)
- changed elliptic curve encryption to use ECIES (as defined in SEC 1)
- changed MARS key schedule to reflect the latest specification
- changed BufferedTransformation interface to support multiple channels
and messages
- changed CAST and SHA-1 implementations to use public domain source
code
- fixed bug in StringSource
- optmized multi-precision integer code for better performance
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Fri, 03 Nov 2000 23:16:25 +0100
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > Tom St Denis wrote:
> > >
> > > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Dumb question: For GF(2^m) with m sufficiently large, are
> > > > there specific tricks in programming that could speed up
> > > > multiplication/division? Thanks.
> > >
> > > I believe you meant GF(2)^m as in a polynomial basis with binary
> > > components. I keep getting mixed up with this as well (although
> people
> > > have explained it...)
> >
> > No. I mean exactly GF(2^m), the finite field of order 2^m
> > (a Galois field that is known to exist). I don't know
> > the mathematical object you referred to or its relationship
> > to GF(2^m).
>
> Um, cuz GF(p) is known as "a finite field with a prime p as a
> modulus". GF(2)^n refers to polynomials of degree 'n' with
> coefficients in GF(2).
I asked a question about GF(2^m), why did you continue
to tell me something about something else???
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Fri, 03 Nov 2000 23:20:54 +0100
Mike Rosing wrote:
>
> Mok-Kong Shen wrote:
> >
> > Dumb question: For GF(2^m) with m sufficiently large, are
> > there specific tricks in programming that could speed up
> > multiplication/division? Thanks.
>
> Yes, there are great many tricks. One major trick is the choice
> of basis. For some field sizes (i.e. depending on m) you can
> get a comparable time for multiply and divide where for m+1 you
> find the divide routine takes 3 times longer than a multiply.
> The use of trinomials makes multiplication faster too.
>
> When m gets very large, say > 1000, you can start using FFT
> methods. I haven't had to program that myself, but it's well
> described in the literature.
I am yet ignorant of literature that gives much details
on comuputational aspects and in particular those points
that you mentioned. Could you please give a couple of
references? Thanks.
M. K. Shen
------------------------------
Subject: example code for your use
From: [EMAIL PROTECTED] (Kenneth Lantrip)
Crossposted-To: comp.lang.c,comp.lang.c.moderated
Date: 03 Nov 2000 23:00:27 GMT
I have written a nice (I think so) little program in C to help me learn the use
of the language. I'm not sure if it's legal to post an encryption algorithm
that uses a 128 bit key. I'd like to offer it to whoever wants to see the code
so that they might can use parts of it or learn from it or whatever.
Below is a text mode screen shot of the program. It is a simple IDEA
calculator that takes an input and a key and makes an output, or an output and
key to find an input. The cursor is moved by the arrow keys and the space bar
toggles the value of the bit or nibble it sits on. F11 saves and F12 loads a
saved state. The program is of no real use, other than educational values, as
the key space and avalanche properties of the IDEA algorithm is too great to be
comprehended by the human mind. It is little more than a crypto-analysis tool
for the algorithm.
If you would like to look over the source code, e-mail me and I'll send it to
ya if ya live in the USA. I'm not sure export laws allow 128 bit crypto
algorithms to be exported. However, I can point you in the right direction to
where you can get the source for the IDEA algorithm that was used in the
program below. I can still send you the main() function.
I realize that these stupid crypto laws are a direct infringement of my first
amendment constitutional right!
_______________________________________________________________________________
Input: 00 01 02 03 04 05 06 07
00000000 00000001 00000010 00000011 00000100 00000101 00000110 00000111
Using Key: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
00000001 00000010 00000011 00000100 00000101 00000110 00000111 00001000
00001001 00001010 00001011 00001100 00001101 00001110 00001111 00010000
Encrypt Subkey:
0000000100000010 0000001100000100 0000010100000110 0000011100001000
0000100100001010 0000101100001100 0000110100001110 0000111100010000
0000100000001010 0000110000001110 0001000000010010 0001010000010110
0001100000011010 0001110000011110 0010000000000010 0000010000000110
0001110000100000 0010010000101000 0010110000110000 0011010000111000
0011110001000000 0000010000001000 0000110000010000 0001010000011000
0101000001011000 0110000001101000 0111000001111000 1000000000001000
0001000000011000 0010000000101000 0011000000111000 0100000001001000
1101000011100000 1111000100000000 0001000000100000 0011000001000000
0101000001100000 0111000010000000 1001000010100000 1011000011000000
0000000000100000 0100000001100000 1000000010100000 1100000011100001
0000000100100001 0100000101100001 1000000110100001 1100000111100010
1100000100000001 0100000110000001 1100001000000010 0100001010000010
Output: 59 4D BB A4 98 27 D4 78
01011001 01001101 10111011 10100100 10011000 00100111 11010100 01111000
_______________________________________________________________________________
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
** 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
******************************
