Cryptography-Digest Digest #211, Volume #10 Thu, 9 Sep 99 15:13:03 EDT
Contents:
(LONG 12K) SHA-1 Implemented in VBA! ("Laurence")
Re: Self decimated lfsr (Medical Electronics Lab)
Re: DES and initial permutation ("David G. Koontz")
Re: "NSA have no objections to AES finalists" (Derek Bell)
Re: (LONG 12K) SHA-1 Implemented in VBA! (DJohn37050)
Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out (Tom Knight)
Re: Different Encryption Algorithms (Anton Stiglic)
Re: some information theory (Mok-Kong Shen)
Re: GnuPG 1.0 released (David A Molnar)
----------------------------------------------------------------------------
From: "Laurence" <[EMAIL PROTECTED]>
Subject: (LONG 12K) SHA-1 Implemented in VBA!
Date: Thu, 9 Sep 1999 18:15:48 +0100
Reply-To: "Laurence" <[EMAIL PROTECTED]>
This is a multi-part message in MIME format.
=======_NextPart_000_000D_01BEFAEF.57BA2FA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hi everybody.
Sorry about the length of this post!
Attached to this post is a module I have recently written which
implements SHA-1 in VBA. I thought that this might be of interest to some
people (probably way off here ;) ).
I do have a concern about this though; is the strength of the SHA algorithm
comprimised by the small-ish strings that this program will hash?
Please note that I am new to crypto and do not have a great maths
background. If I have made any chundering errors, please be easy with me ;)
If anybody has any suggestions, or can code this better, please e-mail me.
--
Laurence Whittle
IT Manager, CIS Ltd.
Director, Astley Whittle Ltd.
=======_NextPart_000_000D_01BEFAEF.57BA2FA0
Content-Type: text/plain;
name="shapost.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="shapost.txt"
Option Compare Database
Option Explicit
' Visual Basic for Applications implementation of the SHA-1 algotithm
'
' Written by Laurence Whittle ([EMAIL PROTECTED]), 9/9/99
'
' This code is postcardware. If you use it, please mention me in your =
about box or
' equivalent and send a postcard, from wherever you live, to 14 Bosworth =
Mews,
' Bournemouth, Dorset, BH9 3SD. England.
'
' Please direct all coments and constructive criticism to =
[EMAIL PROTECTED]
'
'
' Why on earth did I write this? And why in such a crippling language =
as VBA?
'
' I developed a large application in Access which forms the basis of the =
corporate
' information management system. The database is secured using the =
Access built
' in security. Unfortunately this security is somewhat flaky. =
Enforcing that
' every user has a password has proved difficult. So, I decided to =
implement my
' own password system for the database. After reading sci.crypt for a =
while,
' I realised that the best way to enhance your security (note: enhance =
not guarantee)
' is to have the source code available and to chose a well established =
method.
' Well, MS don't exactly hand our their source code. Already I knew =
that the
' best way to store passwords is not to store them. Thankfully a =
one-way hash is
' a great way to resolve this. The hash gives no indication of the =
length of the
' password or any of it's attributes. I chose SHA-1 because this seems =
to be the
' algorithm that is widely accepted as being one of the strongest.
'
' Whilst there are many .DLL and .OCX type applications available 'for a =
small charge',
' this didn't really attract me. Not many of the controls had their =
source code
' available, so there was no guarantee that there was no funny business =
going on behing
' the scenes.
'
' I eventually decided to write the thing myself. I thought it would be =
quite simple
' in VB. However, I was wrong. VBA's data types are not conducive to =
this kind of
' work. Also, as I discovered, the in-built logic functions cannot =
handle true
' 32 bit words. VBA uses (I think) the 32nd bit to make Long Integers =
signed. So,
' functions such as AND, XOR, OR and NOT fail with an overflow message =
if you pass a
' word which has bit 32 set. I have therefore implemented the functions =
lngAND, lngXOR
' lngOR and lngNOT which can handle these values. I admit that these =
functions are
' simplistic at the best, but they work. Also note that I had to use =
the double date
' type to avoid yet more overflow errors.
'
' In fact, all of this code is simple, like me, but it works. I have =
not implemented
' the code to handle strings longer than 55 characters, but, for the =
intended use of
' this code, this is satisfactory.
'
' Using short-ish strings means that the shaDoHash function runs =
instantly on our
' workstations.
'
' Looking through the code you will see that I have had to 'bodge' some =
of the code.
' The bit testing routine falls over if you attempt to use the =
conventional logic
' functions. (Don't forget that the VBA logic functions do not work on =
bit 32)
'
' I hope that somebody finds this module useful. I intend to develop it =
in the future
' to provide the basis for fingerprinting records in a table using a =
hash of the data
' plus the user name.
'
' There is a rudimentary username and password example, which will =
produce a hash
' of the user with their password. This is not intended to be =
definitive.
Type MD_Gen_Buffer
h0 As Double
h1 As Double
h2 As Double
h3 As Double
h4 As Double
A As Double
B As Double
c As Double
D As Double
E As Double
End Type
Type MessageParcel
words(1 To 16) As Double
End Type
Type MessageArray
message(1 To 1) As MessageParcel
End Type
Const K1 As Double =3D 1518500249
Const K2 As Double =3D 1859775393
Const K3 As Double =3D 2400959708#
Const K4 As Double =3D 3395469782#
Const Chars_Per_Parcel =3D 56
Sub shaInit(bff As MD_Gen_Buffer)
bff.A =3D Val("&h67452301")
bff.B =3D Val("&hefcdab89")
bff.c =3D Val("&h98badcfe")
bff.D =3D Val("&h10325476")
bff.E =3D Val("&hc3d2e1f0")
bff.h0 =3D bff.A
bff.h1 =3D bff.B
bff.h2 =3D bff.c
bff.h3 =3D bff.D
bff.h4 =3D bff.E
End Sub
Function f(t, X As Double, y As Double, z As Double) As Double
Dim tmp1 As Double, tmp2 As Double, tmp3 As Double
Select Case t
Case Is <=3D 19
f =3D lngAND(X, y)
f =3D lngOR(f, lngAND((lngNOT(X)), z))
Exit Function
Case Is <=3D 39
f =3D lngXOR(z, (lngXOR(X, y)))
Exit Function
Case Is <=3D 59
tmp1 =3D lngAND(X, y)
tmp2 =3D lngAND(X, z)
tmp3 =3D lngAND(y, z)
f =3D lngOR(lngOR(tmp1, tmp2), tmp3)
Exit Function
End Select
f =3D lngXOR(z, lngXOR(X, y))
End Function
Function S(n As Integer, X As Double) As Double
Dim blk(96) As Boolean, pos As Integer, ctr As Integer, tmp As Double, =
xcopy As Double, xcopy2 As Double
pos =3D 32
For ctr =3D 0 To 31
blk(pos + ctr) =3D GetBitState(X, 31 - ctr)
Next
For ctr =3D 1 To n
blk(pos + 32) =3D blk(pos)
blk(pos) =3D 0
pos =3D pos + 1
Next
S =3D 0
For ctr =3D 0 To 31
tmp =3D 1 And blk(pos + ctr)
S =3D S + tmp * (2 ^ (31 - ctr))
Next
End Function
Function GetBitState(n1 As Double, bit_keep As Integer)
Dim ctr As Double, tmp As Double, tmp2 As Double, bit As Integer
bit =3D bit_keep
tmp =3D n1
For ctr =3D 1 To bit
tmp =3D Int(tmp / 2)
Next
If Int(tmp / 2) =3D tmp / 2 Then ' number is even - bit one not set
GetBitState =3D False
Exit Function
Else
GetBitState =3D True
Exit Function
End If
End Function
Function lngAND(no1 As Double, no2 As Double) As Double
Dim blk1(0 To 31) As Boolean, pos As Integer, ctr As Integer, tmp As =
Double
Dim blk2(0 To 31) As Boolean, tmp2 As Integer, tmp3 As Double
Dim blk3(0 To 31) As Boolean
Dim n1 As Double, n2 As Double
n1 =3D no1
n2 =3D no2
For ctr =3D 31 To 0 Step -1
blk1(ctr) =3D GetBitState(n1, 31 - ctr)
Next
For ctr =3D 31 To 0 Step -1
blk2(ctr) =3D GetBitState(n2, 31 - ctr)
Next
For ctr =3D 31 To 0 Step -1
blk3(ctr) =3D blk1(ctr) And blk2(ctr)
Next
lngAND =3D 0
For ctr =3D 31 To 0 Step -1
tmp =3D 1 And blk3(ctr)
lngAND =3D lngAND + (tmp * (2 ^ (31 - ctr)))
Next
Exit Function
End Function
Function lngOR(no1 As Double, no2 As Double) As Double
Dim blk1(0 To 31) As Boolean, pos As Integer, ctr As Integer, tmp As =
Double
Dim blk2(0 To 31) As Boolean, xcopy2 As Double
Dim blk3(0 To 31) As Boolean
Dim n1 As Double, n2 As Double
n1 =3D no1 ' guarantee that input variables are preserved
n2 =3D no2
For ctr =3D 31 To 0 Step -1
blk1(ctr) =3D GetBitState(n1, 31 - ctr)
Next
For ctr =3D 31 To 0 Step -1
blk2(ctr) =3D GetBitState(n2, 31 - ctr)
Next
For ctr =3D 31 To 0 Step -1
blk3(ctr) =3D blk1(ctr) Or blk2(ctr)
Next
lngOR =3D 0
For ctr =3D 31 To 0 Step -1
tmp =3D 1 And blk3(ctr)
lngOR =3D lngOR + (tmp * (2 ^ (31 - ctr)))
Next
Exit Function
End Function
Function lngXOR(no1 As Double, no2 As Double) As Double
Dim blk1(0 To 31) As Boolean, pos As Integer, ctr As Integer, tmp As =
Double
Dim blk2(0 To 31) As Boolean, xcopy2 As Double
Dim blk3(0 To 31) As Boolean
Dim n1 As Double, n2 As Double
n1 =3D no1 ' guarantee that input variables are preserved
n2 =3D no2
For ctr =3D 0 To 31
blk1(ctr) =3D GetBitState(n1, 31 - ctr)
Next
For ctr =3D 0 To 31
blk2(ctr) =3D GetBitState(n2, 31 - ctr)
Next
For ctr =3D 0 To 31
blk3(ctr) =3D blk1(ctr) Xor blk2(ctr)
Next
lngXOR =3D 0
For ctr =3D 0 To 31
tmp =3D 1 And blk3(ctr)
lngXOR =3D lngXOR + (tmp * (2 ^ (31 - ctr)))
Next
Exit Function
End Function
Function lngNOT(no1 As Double) As Double
Dim blk1(0 To 31) As Boolean, pos As Integer, ctr As Integer, tmp As =
Double
Dim blk3(0 To 31) As Boolean, xcopy2 As Double
Dim n1 As Double
n1 =3D no1 ' guarantee that input variable is preserved
For ctr =3D 31 To 0 Step -1
blk1(ctr) =3D GetBitState(n1, 31 - ctr)
Next
For ctr =3D 31 To 0 Step -1
blk3(ctr) =3D Not blk1(ctr)
Next
lngNOT =3D 0
For ctr =3D 31 To 0 Step -1
tmp =3D 1 And blk3(ctr)
lngNOT =3D lngNOT + (tmp * (2 ^ (31 - ctr)))
Next
Exit Function
End Function
Sub shaStoreString(msg As String, msgblock As MessageParcel)
Dim wd As Integer, offset As Integer, ctr As Integer, pad_length As =
Integer
If Len(msg) <=3D Chars_Per_Parcel - 1 Then
' less 1 because FIPS document example shows that a 56 bit string =
has to be
' split between 2 blocks
wd =3D 1
offset =3D 24
For ctr =3D 1 To Len(msg)
msgblock.words(wd) =3D msgblock.words(wd) Or Asc(Mid(msg, ctr, =
1)) * 2 ^ offset
offset =3D offset - 8
If offset =3D -8 Then
offset =3D 24
wd =3D wd + 1
End If
Next
pad_length =3D Chars_Per_Parcel - Len(msg)
If pad_length > 0 Then
msgblock.words(wd) =3D lngOR(msgblock.words(wd), 128 * 2 ^ =
offset)
End If
msgblock.words(16) =3D Len(msg) * 8
Else
MsgBox "Fatal Error : This SHA-1 Handler only works with text < 55 =
characters long."
End If
End Sub
Sub shaDoHash(msgblock As MessageParcel, bf As MD_Gen_Buffer)
Dim t As Double, temp As Double, temp2 As Double, temp3 As Double, temp4 =
As Double, temp5 As Double
Dim W(0 To 79) As Double
For t =3D 0 To 15
W(t) =3D msgblock.words(t + 1)
Next
For t =3D 16 To 79
W(t) =3D lngXOR(lngXOR(W(t - 3), W(t - 8)), lngXOR(W(t - 14), W(t - =
16)))
W(t) =3D S(1, W(t))
Next
For t =3D 0 To 19
temp =3D S(5, bf.A) + f(t, bf.B, bf.c, bf.D) + bf.E + W(t) + K1
temp =3D lngAND(temp, (2 ^ 32) - 1)
bf.E =3D bf.D
bf.D =3D bf.c
bf.c =3D S(30, bf.B)
bf.B =3D bf.A
bf.A =3D temp
Next
For t =3D 20 To 39
temp =3D S(5, bf.A) + f(t, bf.B, bf.c, bf.D) + bf.E + W(t) + K2
temp =3D lngAND(temp, (2 ^ 32) - 1)
bf.E =3D bf.D
bf.D =3D bf.c
bf.c =3D S(30, bf.B)
bf.B =3D bf.A
bf.A =3D temp
Next
For t =3D 40 To 59
temp =3D S(5, bf.A) + f(t, bf.B, bf.c, bf.D) + bf.E + W(t) + K3
temp =3D lngAND(temp, (2 ^ 32) - 1)
bf.E =3D bf.D
bf.D =3D bf.c
bf.c =3D S(30, bf.B)
bf.B =3D bf.A
bf.A =3D temp
Next
For t =3D 60 To 79
temp =3D S(5, bf.A) + f(t, bf.B, bf.c, bf.D) + bf.E + W(t) + K4
temp =3D lngAND(temp, (2 ^ 32) - 1)
bf.E =3D bf.D
bf.D =3D bf.c
bf.c =3D S(30, bf.B)
bf.B =3D bf.A
bf.A =3D temp
Next
bf.h0 =3D lngAND(bf.h0 + bf.A, (2 ^ 32) - 1)
bf.h1 =3D lngAND(bf.h1 + bf.B, (2 ^ 32) - 1)
bf.h2 =3D lngAND(bf.h2 + bf.c, (2 ^ 32) - 1)
bf.h3 =3D lngAND(bf.h3 + bf.D, (2 ^ 32) - 1)
bf.h4 =3D lngAND(bf.h4 + bf.E, (2 ^ 32) - 1)
' side note : the algorithm assumes that we use 32 bit words and these =
words discard
' bits > 32
End Sub
Function shaHash(inString As String) As String
Dim blk As MessageParcel, buff As MD_Gen_Buffer
shaInit buff
shaStoreString inString, blk
shaDoHash blk, buff
shaHash =3D Str(buff.h0) & Str(buff.h1) & Str(buff.h2) & Str(buff.h3) & =
Str(buff.h4)
End Function
Function ScrambledPass(pwd As String, user As String)
Dim l1 As Integer, l2 As Integer, n As Integer, c As Integer, outstr As =
String
l1 =3D Len(pwd)
l2 =3D Len(user)
outstr =3D ""
If l1 < 6 Or l2 < 6 Then
MsgBox "The user name and password must be atleast 6 characters =
long"
ScrambledPass =3D ""
Exit Function
End If
' find out which is longer
If l2 > l1 Then
c =3D 1
For n =3D 1 To l2
outstr =3D outstr & Str(Asc(Mid(user, n, 1)) Xor Asc(Mid(pwd, c, =
1)))
c =3D c + 1
If c =3D l1 Then c =3D 1
Next
ScrambledPass =3D shaHash(outstr)
Else
' if l1 and l2 are equal, it does not matter which way round we do =
this so
' we allow the 'else' part to handle l1 < l2 and l1=3Dl2
c =3D 1
For n =3D 1 To l1
outstr =3D outstr & Str(Asc(Mid(pwd, n, 1)) Xor Asc(Mid(user, c, =
1)))
c =3D c + 1
If c =3D l2 Then c =3D 1
Next
ScrambledPass =3D shaHash(outstr)
End If
End Function
=======_NextPart_000_000D_01BEFAEF.57BA2FA0==
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Self decimated lfsr
Date: Thu, 09 Sep 1999 12:20:06 -0500
Cairus wrote:
> Thank you very much for your answer. I agree that when you clock only
> once you get a piece of standard sequence; however the attacker can not
> know when you step once and when you step twice, at least if the output
> and the control bit do not coincide. So, honestly I still do not
> understand how he could gain information about the key and which is the
> difference with the case d,k>2.
If I pick [1,2] and have an LFSR sequence 00101100110101100011...
Then my output sequence is 00110010110001...
The 0's tell me that the next bit I see really is the next bit in
the sequence. For the [2,3] case my output is 0001101....
and I have no idea what the bits inbetween any of these was
for the original sequence.
It's a pretty fine point I suppose. An LFSR is not very secure
because if you have enough data you can figure things out
eventually. But if you've got time critical information that only
needs to be secure for a few minutes to an hour, the [2,3] case
would be adequite but the [1,2] case would be good only for a
minute or 2 against a good chunk of hardware.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "David G. Koontz" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: DES and initial permutation
Date: Thu, 09 Sep 1999 11:22:38 -0700
Jim Gillogly wrote:
>
> jerome wrote:
> >
> > i try to understand the aim of the initial permutation in DES. several
> > sources said that there is no cryptanalisys influence.
> > But DES has been designed by knowledgeable people and i dont think
> > they will add a component without explicit reasons.
> >
> > anyone know what is the aim of this initial permutation ?
>
> There are several theories. It is certainly true that it does not make
> the cipher cryptographically stronger. Here are several possibilities.
>
> Theory 1: Permutation is free in hardware... just run the traces somewhere
> else, so why not?
>
> Theory 2: It's there to make the hardware implementation more efficient.
> Schneier: "As near as anyone can tell, its primary purpose is to make it
> easier to load plaintext and ciphertext data into a DES chip in byte-sized
> pieces. Remember that DES predates 16-bit or 32-bit microprocessor busses.)"
>
Actually, there is also the concept of standardization. If one assumes
8 bit I/O, how does one assemble a block? Note that test vectors
are also given to insure bit endian order as well as byte order.
Initial Permutation
___________________
The Initial Permuation is a description of how a byte wide interface
is connected to a 64 bit block (the input block) comprised of two
32 bit blocks (L and R) and is a standardization.
FIPS PUB 46-x has the most significant bit of the input block/byte
as bit 1. Conversion to Bit 7 MSB ( BIT(7) = 1 << 7 ) is shown in the
Byte Bit column in the following tables.
Consider a byte wide interface with the bits numbered 1-8.
The even numbered bits go to the L block, and the odd numbered bits
go to the R block.
Port Byte Input (LR) Left
Bit Bit Block (64 bits) Block (32 bits)
2--------6----------58 50 42 34 26 18 10 2 1 2 3 4 5 6 7 8
4--------4----------60 52 44 36 28 20 12 4 9 10 11 12 13 14 15 16
6--------2----------62 54 46 38 30 22 14 6 17 18 19 20 21 22 23 24
8--------0----------64 56 48 40 32 24 16 8 25 26 27 28 29 30 31 32
Right Block (32 bits)
1--------7----------57 49 41 33 25 17 9 1 1 2 3 4 5 6 7 8
3--------5----------59 51 43 35 27 19 11 3 9 10 11 12 13 14 15 16
5--------3----------61 53 45 37 29 21 13 5 17 18 19 20 21 22 23 24
7--------1----------63 55 47 39 31 23 15 7 25 26 27 28 29 30 31 32
Input Byte 8 7 6 5 4 3 2 1
Consider the Left or Right block being comprised of 4 eight bit registers
serially loaded from the byte wide interface, and during actual encryption
either being parallel loaded (R -> L and f(R,K) XOR L -> R) or the
previous value being held while the key schedule double shifts. During
output (Final Permutation) the shift registers are shifted serially,
the Left block going to odd bits and the Right block going to even bits
(swapping L and R for decryption).
(This means a combination of Theory 1 and 2).
--
remove "no_spam_" from Reply-to address
------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: "NSA have no objections to AES finalists"
Date: 9 Sep 1999 17:31:27 +0100
[EMAIL PROTECTED] wrote:
: Good lord David. You are so paranoid and eager to attack anything
: related to the AES that you are reading stuff into plainly written
: statements. It says absolutely nothing about the government using
: AES for classified data.
Must be Elvis and the space aliens beaming microwaves at him from Area
51 again!
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: (LONG 12K) SHA-1 Implemented in VBA!
Date: 09 Sep 1999 18:33:48 GMT
SHA is defined on and any implementation should work on any length bit string,
including the null length of zero bits. Some implementations restrict to
octets, but the null length and small numbers should still be supported.
Don Johnson
------------------------------
From: Tom Knight <[EMAIL PROTECTED]>
Crossposted-To: rec.arts.sf.written,alt.cyberpunk
Subject: Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out
Date: Thu, 09 Sep 1999 18:33:19 +0100
>
Hmm. IMHO, You seem to be confusing the ideas of the protagonist with
the ideas of the author. I didn't know whether Stephenson himself
supported e-cash before I read Cryptonomicon, and I don't now. However,
anyone could argue that someone can write a tract without actually
believing what it says. A more important point is that I don't really
think that Cryptomomicon, as a book, had any kind of an agenda. I'd
say that Stephenson is far too good an author to fall into the trap of
prolatising(?). The main protagonists favor the system, but the book
makes them all out as, at the very least, mildly unbalanced. Randy is,
in a way, seen as a sane person commenting on an insane situation, but
we are shown his idosincracies(?) as well. I don't think many people
would regard it as promoting some kind of political cause, and I
certainly don't.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Different Encryption Algorithms
Date: Thu, 09 Sep 1999 10:17:53 -0400
You are right, this page does not have any information about the
platform, which is a no no for benchmark summaries.
Here is a much better one:
http://www.eskimo.com/~weidai/benchmarks.html
ignore the other one.
PS. any other suggestion for URL containing benchmarks?
It might be nice to compile them..
Anton
Hideo Shimizu wrote:
> > http://security.nsj.co.jp/products/cstv6/benchmark.html
>
> This page have no information about what platform does benchmark execute.
> I don't see what does it mean by KB/s.
> Do you have any information?
>
> Hideo Shimizu
> TAO, Japan
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: some information theory
Date: Thu, 09 Sep 1999 20:07:14 +0200
Anti-Spam wrote:
>
> For example, let's say this is the message in SYMBOLS:
>
> T H E M E S S.......
>
> when encoded before compression, in binary,
>
> 001001 101011 001001 110111 001001 101010 101010
>
> But, when compressed, T now is encoded as 0111, H as 0011, E as 01, S as
> 10101, M as 1001...
> (just examples, didn't do the math for the encoding.....)
>
> 0111 0011 01 1001 01 10101 10101
>
> We see the bit length of the message is shrinking with the new encoding,
> but note the occurances of the new codes follows the relative ordering
> of the occurances of the uncompressed code. An e no matter how encoded
> still follows the H no matter how encoded. A T starts the message, no
> matter how encoded. We can define a point-set topology on the SYMBOLS
> as they occur in the original message, and we can show that this
> point-set topology is preserved by the compression.
Yes, the same sequence of symbols is there and, of course, the
symbols have the same frequencies as in the original file. But the
analyst looking at the binary string of the compressed file has first
to find out the boundaries between the symbols in the compressed file
(the size of the symbols being non-constant) before he can do any
frequency count. So it could be argued that compression does render
his job more difficult, unless he can somehow obtain knowledge of
the Huffman tree (e.g. in case the table is attached to the data file).
I am interested to know what counter-arguments could be given
against this.
M. K. Shen
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: GnuPG 1.0 released
Date: 9 Sep 1999 18:51:18 GMT
Charles Blair <[EMAIL PROTECTED]> wrote:
> GnuPG says they don't have any patent problems. Did they get
> permissions from McAfee, RSA, PGP partners, etc, or have the patents
> in question expired?
I think one of the design goals of GnuPG was to use only algorithms
without patents, e.g. ElGamal. The PGP message formats are described
as an RFC, so no problems there.
------------------------------
** 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
******************************
