Cryptography-Digest Digest #22, Volume #13 Sat, 28 Oct 00 02:13:01 EDT
Contents:
Re: Is OPT the only encryption system that can be proved secure? (SCOTT19U.ZIP_GUY)
Re: the missed number of messages is more then 130 !!! ("John A. Malley")
Re: Is DES without IP/FP just as strong? (David Hopwood)
ring homomorphic signature and encryption (David A Molnar)
DEFLATE and invalid inputs to decompression (was Re: Rijndael and PGP) (David
Hopwood)
Re: BEST BIJECTIVE RIJNDAEL YET? (Tom St Denis)
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
Re: DEFLATE and invalid inputs to decompression (was Re: Rijndael and PGP)
(SCOTT19U.ZIP_GUY)
how i decode this? (Eduardo Hernandez)
Re: Is OPT the only encryption system that can be proved secure? (JPeschel)
how i decode this?? (Eduardo Hernandez)
Re: how i decode this?? (JPeschel)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: 28 Oct 2000 02:49:43 GMT
[EMAIL PROTECTED] (Douglas A. Gwyn) wrote in
<[EMAIL PROTECTED]>:
>Richard Heathfield wrote:
>> "SCOTT19U.ZIP_GUY" wrote:
>> > The hardest part of scott19u was placing the file in memory and
>> > overlaying on it in various 19bit continuous strurctures that have
>> > different origins that are not offset by 19bits. I really don't
>> > see how to do this in other versions of C.
>
>I don't see why there should be a problem. Since *no* ISA directly
>implements 19-bit aligned addressing, one has to program a
>transformation from the native data layout to/from the 19-bit array
>that scott19u apparently requires. The most convenient method is
>to use an at-least-19-bit wide type for the array element with
>functions or macros for the nontrivial operations such as 19-bit
>rotation. The file to be encrypted should be read through a
>transformer that maps to the 19-bit layout and conversely for the
>output. It isn't hard to create such a transformer; the simplest
>(although not speediest) method is to treat the data as a bit
>stream:
>
>int
>GetBit( FILE *ifp )
> {
> static unsigned char buf; /* buffered input byte */
> static int j = CHAR_BIT; /* next bit # within buf */
> register int next; /* result of getc() */
>
> if ( j == CHAR_BIT ) /* get next byte */
> if ( (next = getc( ifp )) == EOF )
> return -1; /* EOF or error (j still CHAR_BIT) */
> else {
> j = 0;
> buf = next;
> }
>
> return buf >> j++ & 1; /* 0 or 1 */
> }
>
>typedef uint_least32_t word; /* scott19u 19-bit data
>type */ #define WIDTH 19 /* scott19u datum
>effective width */
>
>/* example of macro; to gain speed, extra bits aren't cleared: */
>#define ROTATE_R( w, n ) ((w) >> (n) | (w) << WIDTH - (n))
>
>void
>StoreBit( int b, word base[], size_t i /* bit # within array */ )
> {
> static size_t n = i / WIDTH; /* word # within array */
> static int j = i % WIDTH; /* bit # within word */
>
> /* Warning! assumes base[] is long enough */
>
> if ( b > 0 )
> base[n] |= 1 << j;
> else
> base[n] &= ~(1 << j);
> }
>
>#define MAX 10000 /* or whatever */
>static word data[MAX]; /* input organized as 19-bit words
>*/
>
>size_t
>LoadArray( FILE *ifp )
> {
> size_t i = 0; /* bit # within array */
> int b; /* input bit */
>
> /* Warning! assumes data[] is long enough */
>
> while ( (b = GetBit( ifp )) >= 0 )
> StoreBit( b, data, i++ );
>
> while ( i % WIDTH != 0 )
> StoreBit( 0, data, i++ ); /* padding */
>
> return i / WIDTH; /* # of 19-bit words used */
> }
>
Doug I'm glad you though of it but. SCOTT19U needs to be able
to go through the file in two different directions so I am not
sure the stream idea is useful because I have to travel up the
stream and down the stream unless I revese the file each time.
Unless there is come tricky way to start at back of a file and
wirte the backend first.
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: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: the missed number of messages is more then 130 !!!
Date: Fri, 27 Oct 2000 20:04:58 -0700
jungle wrote:
>
> did anyone notice this ?
> could anyone verify this problem ?
>
I use Compuserve's news server, and I noticed dropped messages as well.
The problem is not as bad as you're reporting but it's definitely there.
The number of missing messages seemed to increase over the past 3 days.
I'm cross-comparing with Deja.com to make sure I'm not missing anything
interesting.
John A. Malley
[EMAIL PROTECTED]
------------------------------
Date: Sat, 28 Oct 2000 05:26:06 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Is DES without IP/FP just as strong?
=====BEGIN PGP SIGNED MESSAGE=====
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> Pascal JUNOD <[EMAIL PROTECTED]> wrote:
> > Tom St Denis wrote:
> > > Yes, without the IP/IP' the cipher is weak when in a CFB-m mode
> > > where m<64.
No, that's not correct (except insofar as DES is weak against brute
force with or without IP/IP^-1).
> > Never heard about such a weakness... Could you give an (academic)
> > reference on this ?
> > How weak ?
>
> http://www.esat.kuleuven.ac.be/~cosicart/ps/VR-9300.ps.gz
This paper shows that IP^-1 slightly *weakens* CFB-m mode against
an attack on DES reduced to 10 rounds or less (i.e. not even an
academic break):
# This differential attack would be impossible without IP^-1.
# In the absence of IP^-1 only information on the output of S-boxes
# of the last round would be available. The security of the DES in
# 1-bit CFB could be improved if the bit is selected from the left
# half of the ciphertext. Selecting all the CFB bits from the left
# half of the ciphertext thwarts the proposed differential attacks
# for small values of m.
# ...
(Note that that this type of attack won't be applicable to any
cipher that has an output mixing stage after the last Feistel round.)
# Conclusions and open problems
#
# Several attacks on the DES in the ECB mode can be extended to
# the m-bit CFB mode. They are only faster than exhaustive key
# search if the number of rounds is reduced [to 10 or less]. ...
# These attacks are completely theoretical in the sense that they
# offer no threat for the DES with 16 rounds in the m-bit CFB mode
# (for 'small' m).
In any case, I doubt this had anything to do with the original
reason for adding IP/IP^-1.
IMHO CFB-m with m < blocksize isn't particularly useful anyway (it
is a factor of blocksize/m slower, and byte-by-byte or bit-by-bit
operation can be achieved just as well with m = blocksize).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOfpVIzkCAxeYt5gVAQHQiwf/YpM+ktJz64fKXraXyk4elF081G/81PIn
kP2tj4/E4jw7UyBGS0EuN6pNHbaXMPw98mbpzBRU/IYg5wLkB3aZAzHtzJ0O2Snb
3yIgyeSi/jhmvDM0o3CZHE9NHGDzR3wSSFJC+ibQPxriC0vi7FodFzHcEHyAJ5QV
ns4X6Qg6B/5bQmMSeOAjKRsb7sB8Vgb0+DAfHJ5+7TBKjigBsxE+koayP6Vyd0/T
ctBbcgtVT4Sw1jX7MbuGYOvGay8wO4oSfciipmw3rNsQc0UJcIqx5ugyEfUqb7x/
L+ikq5qRRUpdRSEjMt8Jbzkehm67Fv/EsGW777gEamopSIOj2yqoiQ==
=Oc3W
=====END PGP SIGNATURE=====
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: ring homomorphic signature and encryption
Date: 28 Oct 2000 04:06:27 GMT
Hi,
This may be a shot in the dark, but -- does anyone know of a signature
scheme which is also a ring homomorphism on, say, Z_N ? an encryption
scheme?
Straight RSA is a multiplicative homomorphism, which makes it a
group homomorphism on Z_N^*. This is for both encryption and signatures.
But it is not an additive homomorphism (indeed, there's a cryptosystem in
EUROCRYPT '99 based on the assumption that it's not an additive
homomorphism). I am interested in a signature scheme which is a
homomorphism for both * and + over Z_N^*.
An encryption scheme with the same properties would be nice, too. The
closest thing I know is the scheme described in Sander, Yung, and Young's
"Non-Interactive CryptoComputing for NC1," which is slightly more general
than a basic group homomorphism but doesn't seem to directly give both +
and *. Also it's an encryption, not a signature, scheme.
Anyone know of anything like this or care to conjecture something?
On a tangential note, are there any known relations between cryptography
and category theory?
Thanks,
-David Molnar
------------------------------
Date: Sat, 28 Oct 2000 05:30:50 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: DEFLATE and invalid inputs to decompression (was Re: Rijndael and PGP)
=====BEGIN PGP SIGNED MESSAGE=====
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> > The truth asshole is that bijective compression has not been out
> > very long so there are fewer methods. And size is not the only way
> > to judge compression when one encrypts but the concept seems beyound
> > your reach of lgoic so I will not go there you can't learn.
>
> Um you're wrong. There are several ways to judge compression but
> it's "security" is not one of them. If the codec has a good ratio,
> uses little resources it's a good codec.
Agreed (in practice patent restrictions are also an important
consideration, since many of the most efficient compression methods
are unfortunately still patented).
> Just because all possible
> inputs decompress into something (which is a property of deflate btw)
> doesn't make it any better/worse.
This is not a property of DEFLATE. A valid DEFLATE input, i.e.
compressed data [*], will have the following properties:
- the last block will have the BFINAL bit set (for files, possibly
not for streams), and other blocks will not,
- the first two bits of a BTYPE field will not be 11,
- in an uncompressed block, the NLEN field will be consistent with
the LEN field,
- a literal/length value will not decode to 286 or 287,
- a string reference will not refer to a position before the start
of the stream.
Inputs that do not satisfy these properties should be rejected by
the decompression function.
In certain situations, the fact that there are some invalid
inputs to decompression might be security-relevant, but not for the
reasons that David Scott suggests. For example, if a public key
encryption scheme were used to encrypt compressed data directly,
then an oracle that reveals whether the compressed data is valid
might be used in a chosen-ciphertext attack (using similar techniques
to Bleichenbacher's attack on PKCS #1 as used in SSL, for instance).
The most appropriate response to that would be to select a public
key encryption scheme that is non-malleable (and hence resistant to
chosen-ciphertext attacks), though, not to change the compression
algorithm.
It's also important to make sure that the implementation of the
decompression function has well-defined behaviour when given an
input that could not have been produced by compression. (zlib, which
is by far the most commonly used DEFLATE implementation, seems to
have been written with this requirement in mind according to some
of the source code comments, although I haven't checked it
exhaustively.)
[*] The DEFLATE spec strictly speaking defines a *decompression*
algorithm; a conforming DEFLATE compressor is anything that
produces output that can be decompressed according to that
algorithm. This allows greater flexibility in trading speed for
compression ratio when implementing compressors.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOfpWNjkCAxeYt5gVAQELzQf/adgZXu4k3Ciwt/FoyEkueOh2zEFcthVp
MphELA9VkVDTnypINyU8T0T8YOA/wYXkm4/9P84QGHFCoSumKEOiNL+9jyCCG3Un
Ope26W7Zzs4N4xehWh1HnoX+5adu/Gm5mT5zd7QQfixXoSJlVXsnzy8PrZwo81Gn
Ro7ACG/zQlk6Xyfl1hRDh7gsQ7DkkPSLVImex19UEi/Fj7DBv7ReNQdDzjqWFHb5
IQGXB6z/tEYucvUDbf/2Y3ph5vlnMKpTbkEe8rymDv+CGnj1OQd3+kRn28oXtn/k
ohM4EPrM9xlKmHxs0WWjDLaaJAsi1fJlUT7PJg6Im1A2w30G+O/dsA==
=npUP
=====END PGP SIGNATURE=====
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: Sat, 28 Oct 2000 04:35:57 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] (Tom St Denis) wrote in
<8tc87m$phb$[EMAIL PROTECTED]>:
>
> >In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> >> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >> : [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> >>
> >> :> If you folks check at comp.compression you we see a note
> >> :> from Matt Timmermans on his super bijective PPM compressor
> >> :> with a built in bijective RIJNDAEL in modied CBC mode.
> >>
> >> [...]
> >>
> >> :> http://www3.sympatico.ca/mtimmerm/bicom/bicom.html
> >>
> >> : Perhaps us "know nothing" people prefer to leave our security to
> >> : security related algorithms.
> >>
> >> I believe that's why the product includes a bijective version of
> >Rijndael
> >> - without that there would be no security at all.
> >
> >Of course Rijndael is bijective it's a friggin block cipher. You
might
> >as well qualify it as a Square-Based Symmetric Keyed Bijective
> >Invertable Permutation Cipher.
> >
>
> Tom you always shot your mouth off with out little thought,
> What other implementaion of Rijndael is really bijective.
> Example the cipher text output file is one bye 0x13 decrypt
> that with a the key of your choice using CBC. You can't unless
> you hava similar program to MATTS I doubt you really understand
> the concept.
Rijndael is not defined for 1-byte blocks so technically what "matt"
did is not Rijndael. Of course I could use Rijndael in a feedback mode
(OFB) to get a keystream and encode 5-bit msgs if I like.
So what?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 28 Oct 2000 05:20:54 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in <8tdl3e$v03$[EMAIL PROTECTED]>:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> [EMAIL PROTECTED] (Tom St Denis) wrote in
><8tc87m$phb$[EMAIL PROTECTED]>:
>>
>> >In article <[EMAIL PROTECTED]>,
>> > [EMAIL PROTECTED] wrote:
>> >> Tom St Denis <[EMAIL PROTECTED]> wrote:
>> >> : [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> >>
>> >> :> If you folks check at comp.compression you we see a note
>> >> :> from Matt Timmermans on his super bijective PPM compressor
>> >> :> with a built in bijective RIJNDAEL in modied CBC mode.
>> >>
>> >> [...]
>> >>
>> >> :> http://www3.sympatico.ca/mtimmerm/bicom/bicom.html
>> >>
>> >> : Perhaps us "know nothing" people prefer to leave our security to
>> >> : security related algorithms.
>> >>
>> >> I believe that's why the product includes a bijective version of
>> >Rijndael
>> >> - without that there would be no security at all.
>> >
>> >Of course Rijndael is bijective it's a friggin block cipher. You
>might
>> >as well qualify it as a Square-Based Symmetric Keyed Bijective
>> >Invertable Permutation Cipher.
>> >
>>
>> Tom you always shot your mouth off with out little thought,
>> What other implementaion of Rijndael is really bijective.
>> Example the cipher text output file is one bye 0x13 decrypt
>> that with a the key of your choice using CBC. You can't unless
>> you hava similar program to MATTS I doubt you really understand
>> the concept.
>
>Rijndael is not defined for 1-byte blocks so technically what "matt"
>did is not Rijndael. Of course I could use Rijndael in a feedback mode
>(OFB) to get a keystream and encode 5-bit msgs if I like.
>
>So what?
It means when you said Rijndael was bijective by itself
it was a fucking lie, It depends on how it is implimented.
Matt did it correctly. If he really wanted to he could of used
twocrap or any other block cipher. Look you may not like it
but do you know of any other program that incorpartes high
grade compression with what is condsidered by some to be
strong encryption that is fully bijective YES or NO.
My guess is you don't know
of any and you will rant on so that you can have the last
word. And further more what Matt did was pure Rijndael but
your pee brain can't seem to understand that.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: DEFLATE and invalid inputs to decompression (was Re: Rijndael and PGP)
Date: 28 Oct 2000 05:12:13 GMT
[EMAIL PROTECTED] (David Hopwood) wrote in
<[EMAIL PROTECTED]>:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Tom St Denis wrote:
>> In article <[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> > The truth asshole is that bijective compression has not been out
>> > very long so there are fewer methods. And size is not the only way
>> > to judge compression when one encrypts but the concept seems beyound
>> > your reach of lgoic so I will not go there you can't learn.
>>
>> Um you're wrong. There are several ways to judge compression but
>> it's "security" is not one of them. If the codec has a good ratio,
>> uses little resources it's a good codec.
>
>Agreed (in practice patent restrictions are also an important
>consideration, since many of the most efficient compression methods
>are unfortunately still patented).
I some what agree with you and still owe you that beer. Tom
often goes in to left field I was never talking about security of
compression but in some message about how compression can affect
the security of an overall compression encryption combination.
>
>> Just because all possible
>> inputs decompress into something (which is a property of deflate btw)
>> doesn't make it any better/worse.
>
>This is not a property of DEFLATE. A valid DEFLATE input, i.e.
>compressed data [*], will have the following properties:
Tom last year admitted deflate did not have this property
so I guess he is getting confusted in his hate. I did not respond
to him since it was a waste of my time. And his response is always
to rant about something else.
>
> - the last block will have the BFINAL bit set (for files, possibly
> not for streams), and other blocks will not,
> - the first two bits of a BTYPE field will not be 11,
> - in an uncompressed block, the NLEN field will be consistent with
> the LEN field,
> - a literal/length value will not decode to 286 or 287,
> - a string reference will not refer to a position before the start
> of the stream.
>
>Inputs that do not satisfy these properties should be rejected by
>the decompression function.
>
>In certain situations, the fact that there are some invalid
>inputs to decompression might be security-relevant, but not for the
>reasons that David Scott suggests. For example, if a public key
>encryption scheme were used to encrypt compressed data directly,
>then an oracle that reveals whether the compressed data is valid
>might be used in a chosen-ciphertext attack (using similar techniques
>to Bleichenbacher's attack on PKCS #1 as used in SSL, for instance).
>The most appropriate response to that would be to select a public
>key encryption scheme that is non-malleable (and hence resistant to
>chosen-ciphertext attacks), though, not to change the compression
>algorithm.
I don't think you can prove a public key compression scheme is
resistant to chosen ciphertext attacks. Since there are many ways
to do such attacks. Some may be resistant to "known open" chosen
-ciphertext attacks but the NSA may have better methods not known
in the open literature.
>
>It's also important to make sure that the implementation of the
>decompression function has well-defined behaviour when given an
>input that could not have been produced by compression. (zlib, which
>is by far the most commonly used DEFLATE implementation, seems to
>have been written with this requirement in mind according to some
>of the source code comments, although I haven't checked it
>exhaustively.)
I doubt that it is. But I like to get hands on code to test.
but the main data encryption portion can not be bijective since
they do a partailly encode the key in the main text so that a quick
check can be done to see if user is using the correct key. If they
want real security there would be a mode where this could be turned
off. Why give any additional info to an attacker.
I wish you would look at Matts bicom and see what you think
Take Care
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: Eduardo Hernandez <[EMAIL PROTECTED]>
Subject: how i decode this?
Date: Fri, 27 Oct 2000 21:26:53 -0400
how i decode or decrypt this kind of messages???
eg.
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&)>/>
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: 28 Oct 2000 05:36:31 GMT
SCOTT19U.ZIP_GUY writes, in part:
>Unless there is come tricky way to start at back of a file and
>wirte the backend first.
Here's some code, whose origin I'm not sure
of, that reads and writes a file backwards.
I used it to help crack Wizzard's Encrypto!
a few years ago. For some reason the
authors thought writing the encrypted file
backwards would make it more secure.
You'll need a fast way to find the file
size: maybe a combination of fseek and
ftell.
#include <stdio.h>
#include <stdlib.h>
static void *
reverse (void *s, size_t sz)
{
char *p, *q, temp;
p = s, q = p + sz - 1;
while (p < q) {
temp = *p, *p = *q, *q = temp;
p++, q--;
}
return s;
}
static int
ftac (char *filename, long filesize)
{
char buf[2][BUFSIZ];
long offset_beg, offset_end;
long dif;
long sz = BUFSIZ;
FILE *fp = fopen (filename, "r+b");
if (fp == 0) return -1;
offset_beg = 0;
offset_end = filesize;
while ((dif = offset_end - offset_beg) > 1) {
if (dif/2 < sz) sz = dif/2;
offset_end -= sz;
fread (buf[0], 1, sz, fp);
fseek (fp, offset_end, SEEK_SET);
fread (buf[1], 1, sz, fp);
fseek (fp, offset_end, SEEK_SET);
fwrite (reverse (buf[0], sz), 1, sz, fp);
fseek (fp, offset_beg, SEEK_SET);
fwrite (reverse (buf[1], sz), 1, sz, fp);
offset_beg += sz;
}
fclose (fp);
return 0;
}
int
main (int argc, char *argv[])
{
if (argc != 3)
exit ((fprintf (stderr, "usage: ftac [filename] [filesize]\n"),
EXIT_FAILURE));
if (ftac (argv[1], atoi (argv[2])) == -1)
exit (EXIT_FAILURE);
return 0;
}
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Eduardo Hernandez <[EMAIL PROTECTED]>
Subject: how i decode this??
Date: Fri, 27 Oct 2000 21:28:48 -0400
how i decode or decrypt this kind of messages???
eg.
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&)>/>
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: how i decode this??
Date: 28 Oct 2000 05:58:19 GMT
[EMAIL PROTECTED] writes, in part:
>how i decode or decrypt this kind of messages???
>
>eg.
>
>MQ'(E<H8.=8"AKS*7C$$KTGXXF_-D:M+&![;'PY61C0<B$-?E1B.^XK
It's UUencoded. You need a UUdecoder. Winzip
can handle the decoding.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
** 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
******************************
