Cryptography-Digest Digest #836, Volume #13 Thu, 8 Mar 01 12:13:01 EST
Contents:
Re: The Foolish Dozen or so in This News Group (Troed)
Re: => FBI easily cracks encryption ...? (I am out) ("kroesjnov")
Re: PKI and Non-repudiation practicalities (Anne & Lynn Wheeler)
Re: qrpff-New DVD decryption code (SCOTT19U.ZIP_GUY)
Re: Dayton's Code Breakers (Jim Steuert)
Re: Super strong crypto ("Douglas A. Gwyn")
frequency "flattening" (Joe H. Acker)
Re: Super strong crypto ("Douglas A. Gwyn")
Re: Super strong crypto ("Douglas A. Gwyn")
Re: Q: Tempest Systems ("Douglas A. Gwyn")
Re: frequency "flattening" (Neil Couture)
Re: hardwire prime & generator in Diffie-Hellman? (DJohn37050)
Re: The Foolish Dozen or so in This News Group ("Scott Fluhrer")
Re: NTRU - any opinions (DJohn37050)
Re: PKI and Non-repudiation practicalities (Anne & Lynn Wheeler)
Re: OT: TV Licensing (Was: => FBI easily cracks encryption ...?) (Richard Herring)
Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily cracks (Richard
Herring)
Re: Really simple stream cipher ("Scott Fluhrer")
Re: Really simple stream cipher ("Henrick Hellström")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Troed)
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Reply-To: [EMAIL PROTECTED]
Date: Thu, 08 Mar 2001 15:15:51 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>This is a personal use program for windows. I think it is fair to
>say this program is for and intended for a non multitasking
>environment.
It's for Windows 3.x only? Windows 95 and up are pre-emptive
multitasking - or what are you talking about?
>Take a look at my floppy disk test results I just posted. They seem
>to cramp everything pretty much all the detractors have been saying.
Floppy != Harddrive
___/
_/ - Software Engineer working in the development of operating
systems
------------------------------
From: "kroesjnov" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...? (I am out)
Date: Thu, 8 Mar 2001 16:12:24 +0100
k peeps
I am out off this duscussion
This lead nowhere for me
nice chatting with you al (I guess)
"Wisdom lies not in obtaining knowledge, but in using it in the right way"
kroesjnov
email: [EMAIL PROTECTED] (remove nov to reply)
UIN: 67346792
pgp fingerprint: 4251 4350 4242 7764 80DA DB1C E2B2 850A DF15 4D85
------------------------------
Subject: Re: PKI and Non-repudiation practicalities
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2001 15:17:07 GMT
[EMAIL PROTECTED] (Mark Currie) writes:
> Hi,
>
> Ok, I see now where you changed to discussing this model (AADS). I am not
> familiar with this model, I guess that I will have to visit your site. It
> sounds interesting.
>
> Mark
as per prior note ... after working on
http://www.garlic.com/~lynn/aadsm5.htm#2
http://www.garlic.com/~lynn/aadsm5.htm#3
http://www.garlic.com/~lynn/aadsm5.htm#4
http://www.garlic.com/~lynn/aadsm5.htm#1
it seemed to be worthwhile to look at a public key infrastructure
model that preserved the existing trust and business process models.
random refs:
http://www.garlic.com/~lynn/aadsover.htm
http://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt
http://www.garlic.com/~lynn/aadswp.htm
CAs and certificates were an design point to address trust in offline
email where little or no trust processes existed ... which might show
a net benefit. However, introducing a new trust participant in
existing value transactions containing significant number of stake &
trust members is a very, very difficult business process. If the
argument is purely based on better authentication technology .... then
do an implementation that is a technology public key infrastructure
w/o having to introduce new trust partners into every transaction.
For a technology demonstration, a CA-base with certificates is a
possibly less expensive demo scenerio i.e. a couple thousand
certificates and some boundary demonstration of signed transaction
which then are converted into standard business form and processed in
the normal way. Somebody takes a risk acceptance on the fact that the
limited demo isn't integrated into the standard trust and business
processes. The trade-off is the integration of the public key
infrastructure into the existing business & trust processes (1-5% of
the existing data processing infrastructure costs) versis scaling a
CA-base with certificates into a duplicate of the existing business &
trust processes (100% of the existing data processing infrastructure
costs) plus syncronizing the CA-base and the existing base for things
like referential integrity (possibly another 100% of the base).
The cut-over from the CADS-model for demo purposes to integrated
AADS-model would be at 1-5% of the account base plus any risk exposure
because of a non-integrated operation.
Part of some of the AADS-model scenerios has been trying to
demonstrate overall cost savings converting to public key
infrastructure authentication from existing business authentication
methods (i.e. various benefits are larger than the cut-over costs).
Part of that is looking for existing transition activities and attempt
to merge a AADS-model transition into some transition that is already
going to be done and has been cost justified for other reasons.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.hackers.malicious
Subject: Re: qrpff-New DVD decryption code
Date: 8 Mar 2001 15:18:35 GMT
[EMAIL PROTECTED] (Mach) wrote in
<[EMAIL PROTECTED]>:
>If DVD players already contain decryption code, why do we need
>decryption software?
There are 2 Main reason for needing the sofware. One you
use a good operating systme like Linux the DVD people don't
like freedom or open source. The second reason is you live
in a border down like EL Paso. And you buy DVD and want to play
or you get them from relatives in Juarez a stone through away.
The DVD are set up to decode based on where you live. IF you
get one for the US you can't play ones for mexico. Some DVDs
can olny change setting 3 times. People here own DVD that are
read in MExico or US only. This causes a big problem since you
legally own the DVD some may have been a gift. But if you have
both types of DVDS and many people do. THey get bit in the ass
when they try to play and switch settings after only a few short
times. I think the DVD encryption based on country code is not
only crap but should be illegal. So people writting code to
allow one to use ones on DVDs is a great service.
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: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: Dayton's Code Breakers
Date: Thu, 08 Mar 2001 11:10:58 -0500
Thanks,
Excellent article.
Jerry Proc wrote:
> Hi Folks,
>
> There was a multi-part story in the Dayton Daily news about the man who
> headed up the National Cash Register team that built 120 bombes for US
> Navy in WWII
> in order to crack codes generated by the German 4-rotor Engima.
>
> See Dayton's Code Breakers http://www.activedayton.com/partners/ddn/
>
> Read about the problems encountered after it was discovered that
> designing a Bombe with 70,000 gas-filled tubes was impractical! The
> links to the
> articles are at the bottom centre of the Dayton News home page.
>
> [Via Brookes Crypto pages]
>
> --
> Jerry Proc VE3FAB
> http://webhome.idirect.com/~jproc/crypto
> e-mail:[EMAIL PROTECTED]
> http://www3.sympatico.ca/hrc/haida
> HMCS HAIDA Historic Naval Ship. Toronto, Ontario
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Thu, 8 Mar 2001 15:20:26 GMT
"Douglas A. Gwyn" wrote:
> David Wagner wrote:
> > k = DES_0(x) xor AES_0^{-1}(c)
> Okay, by engineering the block function to have this property,
> naturally you can exploit it without having to do much work.
It should also be noted that that attack was against the phase 2
straw man; for phase 3, instead of (known) x one has to use
x xor iv (iv is the unknown random mask), so DES_0(x xor iv) is
infeasible and k is not recovered. It's to protect against
stuff like that that phase 3 introduced the mask.
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: frequency "flattening"
Date: Thu, 8 Mar 2001 16:55:29 +0100
Hi!
As a followup to my other post, I have a question that is related to
Huffman-Coding. Before I re-invent the wheel, I ask here.
I am looking for a sort of "expansion" function that should work like
that:
We have n signs of alphabet A, e.g. let's suppose n=256. There's an
arbitrary length plaintext PT composed of the alphabet. There's a
function f_PT(x) that returns the frequency of x in PT.
Aim: Find an optimal code C that maps any sign of PT to a sign or
sequence of signs in CT (and vice versa), such that f_CT(x) = k is a
constant value k for any arbitrary sign x of CT.
Does Huffman-Coding does this? I'm not sure, so if not, how is this
algorithm called and where can I find information about it?
Regards,
Erich
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Thu, 8 Mar 2001 15:39:06 GMT
Mok-Kong Shen wrote:
> I have argued in a follow-up (7-th Mar) that it is preferable
> to transmit the new keys with a separate dedicated key.
> (This effectively means sending the new keys via another
> (logical) channel.) I don't yet see the point of attempting
> (hard) to safely embed the new keys in the way you proposed,
> if the other way is quite clear-cut and readily available
> in practice.
In many applications, including the one I have in mind, there
is only one actual data channel, so you'd need to multiplex
that, but that's not a significant problem. The reason I
didn't take that approach is that you require roughly twice
as much key material for a comparable amount of security.
I was trying to stretch safe use of available key material
as far as possible.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Thu, 8 Mar 2001 15:46:50 GMT
David Wagner wrote:
> Ok. To help me understand, can you define "fairly good" more precisely,
> then? For instance, does "fairly good" imply that the cipher is secure
> against all attacks where the adversary knows just a single block of
> known-text?
No, because that would be begging the question.
The reason for phase 3 (PT mask) was to protect against
*unknown* forms of single-block known-plaintext attack;
there is simply more unknown information than known
information (by 128 bits using my originally suggested
parameters), so instead of a single solution Eve has to
try a class of 2^128 solutions, the further checking of
which is infeasible.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Q: Tempest Systems
Date: Thu, 8 Mar 2001 15:55:38 GMT
"news.singnet.com.sg" wrote:
> The captors of course have set up a tempest system to capture signals and
> visuals from his notebook computer and the methods he uses to throw them off
> track are quite clever.
> Any comments on this? Would never happen? Tempest systems aren't that good?
It is easier to apply eavesdropping technology to emanations from a CRT
than from a laptop, but that doesn't mean that the latter is impossible.
Indeed, operate your computer without the shielding in place near an
analog TV (PAL/SECAM/NTSC) antenna and you will probably see
interference
on the TV display. That indicates that the computer is broadcasting RF,
and regularity in the interferemce (not just "snow") indicates that the
RF has a high degree of coherence, so it is relatively easy to
correlate.
Many current technologies require continual refresh, which means that
the same signal will be transmitted repeatedly; that allows the signal
to be pulled from the noise through correlation techniques.
------------------------------
From: Neil Couture <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: frequency "flattening"
Date: Thu, 08 Mar 2001 16:29:04 GMT
"Joe H. Acker" wrote:
> Hi!
>
> As a followup to my other post, I have a question that is related to
> Huffman-Coding. Before I re-invent the wheel, I ask here.
>
> I am looking for a sort of "expansion" function that should work like
> that:
>
> We have n signs of alphabet A, e.g. let's suppose n=256. There's an
> arbitrary length plaintext PT composed of the alphabet. There's a
> function f_PT(x) that returns the frequency of x in PT.
>
> Aim: Find an optimal code C that maps any sign of PT to a sign or
> sequence of signs in CT (and vice versa), such that f_CT(x) = k is a
> constant value k for any arbitrary sign x of CT.
>
First of all it would be cool to define exactly want is optimal for you.
but anyway i can maybe guess that you want to optimize for memory.
( as so Huffman code can help you ).
>
> Does Huffman-Coding does this? I'm not sure, so if not, how is this
> algorithm called and where can I find information about it?
>
> Regards,
>
> Erich
Huffman Code is a type a compression. where particular symbols of
alphabet
are encoded according to their frequency. Usualy you would encode the
most
frequency symbol of your alphabet with '1' ( say 'e' in french... ). that
is here
the most frequent sign is encoded with the minimum lenght of information.
and so on. The Huffman Code then construct a binary of all the symbols
according
to their frequency distribution. The tree is made such that no ambiguity
is
possible when reading the compressed data.
Anyway the primary goal with Huffman code is the compress data. I hope
this helps you. i did not dvelve to much into the details....
Neil
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 08 Mar 2001 16:35:58 GMT
Subject: Re: hardwire prime & generator in Diffie-Hellman?
See IEEE 1363 for a lot of good recommendations and discussion of concerns.
There are lots of mines to avoid, depending.
Don Johnson
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Thu, 8 Mar 2001 08:28:30 -0800
Troed <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
> >This is a personal use program for windows. I think it is fair to
> >say this program is for and intended for a non multitasking
> >environment.
>
> It's for Windows 3.x only? Windows 95 and up are pre-emptive
> multitasking - or what are you talking about?
Actually, Windows 3.1 is also multitasking, at least in 386 mode. Windows
API programs could not get at that facility, but other subsystems (most
usually, "DOS Windows") could, and did.
>
> >Take a look at my floppy disk test results I just posted. They seem
> >to cramp everything pretty much all the detractors have been saying.
>
> Floppy != Harddrive
And in addition, one test on one version of Windows with on particular
Windows settings and one particular file system does not say anything in
particular about what may happen on another.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 08 Mar 2001 16:39:48 GMT
Subject: Re: NTRU - any opinions
ECC is very suited to constrained environments, having short keys and sigs and
simple key gen. It is not cleat at all to me that NTRU is as suited as it has
longer keys than even RSA, longer sigs than RSA, not studied key gen yet but I
do not see how anything can be simpler than ECC. It seems to be faster than
RSA on NTRU's implementations but they also seem to say that ECC SigGen is
slower then SigVer which does not compute.
Don Johnson
------------------------------
Subject: Re: PKI and Non-repudiation practicalities
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Thu, 08 Mar 2001 16:37:36 GMT
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
> http://www.garlic.com/~lynn/aadsm5.htm#2
> http://www.garlic.com/~lynn/aadsm5.htm#3
> http://www.garlic.com/~lynn/aadsm5.htm#4
> http://www.garlic.com/~lynn/aadsm5.htm#1
oops, finger slip
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn4
http://www.garlic.com/~lynn/aadsm5.htm#asrn1
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: OT: TV Licensing (Was: => FBI easily cracks encryption ...?)
Date: 8 Mar 2001 16:42:18 GMT
Reply-To: [EMAIL PROTECTED]
In article <WOtp6.930$[EMAIL PROTECTED]>, John Niven
([EMAIL PROTECTED]) wrote:
> > (You have to own a license to watch TV in Britain? Fortunately I have a
> > simple solution for that, having not watched TV at all for years... by
> > choice.)
> Not quite right - you have to own a license to own a TV. Subtle, but it
> meant that the small colour set I had solely to use with my "micro-computer"
> during the 80's required a license.
Subtler than that. It's true that the legal test is not whether
you operate the TV, but you don't have to have a licence to *own* a TV.
You do have to have a licence to "install a receiving station".
If you want to know what that means, hire a lawyer.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily cracks
Date: 8 Mar 2001 16:59:03 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, William Hugh Murray
([EMAIL PROTECTED]) wrote:
> > Nazi Germany, came to power through
> > constitutionally legitimate means.
> Not true. Please go back and read the history again. It is well documented
> that the Nazis came to power by terror, not by democratic process.
The two are not mutually exclusive.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Thu, 8 Mar 2001 08:55:02 -0800
Henrick Hellström <[EMAIL PROTECTED]> wrote in message
news:9883rt$2fe$[EMAIL PROTECTED]...
> "Scott Fluhrer" <[EMAIL PROTECTED]> skrev i meddelandet
> news:98729g$vii$[EMAIL PROTECTED]...
> > - The attacker guesses the lsbits of the initial values of V[0], V[1],
> K[0],
> > K[1]. Note that there are only 16 possible guesses.
> >
> > - For each of these 16 possible guesses, decrypt the ciphertext and
> produce
> > the lsbits of the plaintext (looking at the plaintext/ciphertext as a
> > sequence of 32 bit values). Note that, because the cipher lacks any
> > diffusion whatsoever from the higher order bits to the lower order bits,
> he
> > can do this ambiguously, using essentially the same algorithm as the
> > intended receiver does.
> >
> > - Examine the 16 possible sequences of plaintext lsbits, and decide
which
> > one looks most like the lsbits of real plaintext. Note that this is
> usually
> > possible, in that the lsbits of a plaintext message usually don't look
> > particularly random
> >
> > - Now that you have a good guess at the lsbits of the initial values of
> > V[0], V[1], K[0], K[1], start in on the second lsbit.
> >
> > - Repeat until you have all the bits.
> >
> > Moral of the story: diffusion is a *really* good idea..
>
> Aaah! The cipher really could be broken, but from my point of view you
> failed to explain why: Every other qword of plain text corresponds to a
new
> random value of K, and your attack does not account for that. Your method
> would not be sufficient derive any single one of the values K, V or P
given
> only a single qword of cipher text (although you would be able to exclude
> some of the possibilities).
Who said an attack had to be limited to a single qword of cipher text? In
that sense, 3DES is also informationally secure, in that you cannot uniquely
rederive the key from a single plaintext/ciphertext block.
And, my attack does account for new values of K. I did not say so
explicitly because there was no need. In fact, the fact that you consider K
to be a "key", and the fact that you update it with randomness, is of no
particular significance -- it is just more state (just like V) which is
updated at times during the cipher.
Lets go through the attack again:
- First, we note that, if the attacker was given the correct initial values
of V[0], V[1], K[0], K[1], then he could decrypt the message (not just a
single qword, but the entire message), by using precisely the same algorithm
that the intended receiver does. The randomly updated K does not prevent
the attacker from a correct decryption no more than it does the intended
receiver.
- Then, let us consider what would happen if the attacker was given values
of V[0], V[1], K[0], K[1] that was correct in their least significant bits,
but may be incorrect elsewhere. I claim that, if you use those values in
the decryption algorithm, the "plaintext" (again, not of a single qword, but
the entire message) you get back has the correct values in its least
significant bits, but may be incorrect elsewhere.
- Hence, by cycling through all 16 possibilities, the attacker can use all
16 settings to produce 16 possible "lsbits of message", and look at all 16,
and decide which looks the most likely. I claim that, for most realistic
plaintexts, that such a determination should be simple.
- Once he has a good guess at the lsbits of V[0], V[1], K[0], K[1], he can
start in on the 2 lsbits (and, given that he knows the lsbits, that's only
16 more possibilities), and continue in the obvious way.
This "you can attack key bits individually" property of the cipher reduces
the effort from the obvious 2**(32*4) to 32 * 2**4 == 2**9. The random
updates of K really do not alter this property.
--
poncho
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Thu, 8 Mar 2001 18:05:57 +0100
OK, here is an improvement. It requires an OTP, but it doesn't increase the
bandwidth and is infinitely error propagating past a single cipher text
error.
Consequently, the interesting question in this case is whether or not there
is an attack against the error propagation. Is there a way to make it stop
using multiple cipher text substitutions? Relevant assumptions are that the
adversary is not the legitimate sender, that the adversary does not know
V or OTP, and that V and OTP are not used more than once.
"Henrick Hellström" <[EMAIL PROTECTED]> skrev i meddelandet
news:986t9e$7v4$[EMAIL PROTECTED]...
>
> Algo AEnc:
>
> Input qword V, K; dword P
> Output qword V, dword C
>
0. V[0] := V[0] rol 1; V[1] := V[1] rol 1
> 1. V[1] := V[1] + V[0]
> 2. V := V xor K
> 3. C := P xor V[0]
> 4. V[0] := V[1]; V[1] := C
>
>
> Algo BEnc:
>
> Input qword V,K,P
> Output qword V,C
>
> 1. AEnc(V,K,P[0],C[0])
> 2. AEnc(V,K,P[1],C[1])
>
>
> Algo CEnc:
>
> Input qword V,P; qword array OTP; integer Index
> Output qword V,C
>
0. K := OTP[Index]
> 1. BEnc(V,K,P,C)
Here is some Delphi test code for the cipher scaled down from qword size to
byte size. TestErrorPropagation is (of course) a test of the error
propagation past a single cipher text error. TestBruteForce performs a brute
force known plain text attack and is always able to find values of K
independently of the initial value of V and independently of the length of
the message.
function RolByte(Value: Byte): Byte;
asm
(* x86 assembler code. The two nibbles of Value are rotated separately. *)
ROL AL,1
MOV DL,AL
AND AL,$EE
AND DL,$11
ROL DL,4
OR AL,DL
end;
procedure KS8Enc(K: Byte; var V, T: Byte);
type
Nibble = 0..15;
var
V1, V0: Byte;
C0, C1: Nibble;
begin
(* Encrypt first nibble: *)
V0 := RolByte(V);
V0 := (V0 and $F) +
((V0 + (V0 shr 4))) shl 4;
V0 := V0 xor K;
C0 := (T xor V0) and $F;
V1 := RolByte((V0 shr 4) + (C0 shl 4));
(* Encrypt second nibble: *)
V1 := (V1 and $F) +
((V1 + (V1 shr 4))) shl 4;
V1 := V1 xor K;
C1 := ((T shr 4) xor V1) and $F;
V := (V1 shr 4) + (C1 shl 4);
T := C0 + (C1 shl 4);
end;
procedure KS8Dec(K: Byte; var V, T: Byte);
type
Nibble = 0..15;
var
V1, V0: Byte;
P0, P1: Nibble;
begin
V0 := RolByte(V);
V0 := (V0 and $F) +
((V0 + (V0 shr 4))) shl 4;
V0 := V0 xor K;
P0 := (T xor V0) and $F;
V1 := RolByte((V0 shr 4) + ((T and $F) shl 4));
V1 := (V1 and $F) +
((V1 + (V1 shr 4))) shl 4;
V1 := V1 xor K;
P1 := ((T shr 4) xor V1) and $F;
V := (V1 shr 4) + (T and $F0);
T := P0 + (P1 shl 4);
end;
procedure TestErrorPropagation;
var
K, V, V0, VE: Byte;
B, C: Byte;
I: Int64;
begin
Randomize;
V0 := Random(256);
V := V0;
VE := V0;
B := Random(256);
C := B;
KS8Enc(K,V,C);
E := Random(15) + 1;
Memo1.Lines.Add(Format('Error: %x',[E]));
C := C xor E; KS8Dec(K,VE,C);
I := 1;
while I <= 512 do begin
K := Random(256);
B := Random(256);
C := B;
KS8Enc(K,V,C);
KS8Dec(K,VE,C);
if V = VE then begin
Memo1.Lines.Add(Format('EP worn out at %d',[I]));
Exit;
end;
Inc(I);
end;
Memo1.Lines.Add('Failure.');
end;
procedure TestBruteForce(Sender: TObject);
const
TextLen = $1000;
var
Po, I, J: Integer;
OrgK, OrgV, K, V, pV, C, P: Byte;
CT: string;
OK: Boolean;
begin
Randomize;
OrgV := Random(256);
Memo1.Lines.Add(Format('---'#13#10'Actual V: %d'#13#10,[OrgV]));
CT := '';
V := OrgV;
for Po := 1 to TextLen do begin
K := Random(256);
P := 0;
C := P;
KS8Enc(K,V,C);
CT := CT + Char(C);
end;
for OrgV := 0 to 255 do begin
pV := OrgV;
for Po := 1 to TextLen do begin
OK := False;
for K := 0 to 255 do begin
C := Byte(CT[Po]);
V := pV;
KS8Dec(K,V,C);
if C = 0 then begin
OK := True;
Break;
end;
end;
if not OK then Break;
pV := V;
end;
if OK then
Memo1.Lines.Add(Format('V: %d',[OrgV]));
end;
end;
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
** 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
******************************
