Cryptography-Digest Digest #313, Volume #14 Tue, 8 May 01 06:13:01 EDT
Contents:
Re: RIP Act and OTP (SCOTT19U.ZIP_GUY)
Re: ISO 9796-1:1991 (Anders Thulin)
Re: Black & white .gifs? (Benjamin Goldberg)
Re: RSA BRUTE FORCE ("Joseph Ashwood")
Re: Best, Strongest Algorithm ("Joseph Ashwood")
Re: Intacta.Code ... ("Joseph Ashwood")
Re: IV question !! (Snot)
Steganographic idea. (Benjamin Goldberg)
Re: Random and not random (Mok-Kong Shen)
Re: Random and not random (Bryan Olson)
Re: free en/decryption library (yomgui)
Re: Note on combining PRNGs with the method of Wichmann and Hill (Mok-Kong Shen)
Question about randomness and OTPs (Joe H Acker)
Re: Tiny s-boxes (Mark Wooding)
Re: Random and not random (Mok-Kong Shen)
Re: Ciphertext only ("Joseph Ashwood")
Re: free en/decryption library (Mark Wooding)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: RIP Act and OTP
Date: 8 May 2001 06:54:21 GMT
[EMAIL PROTECTED] (Joseph Ashwood) wrote in <Ous5SBf0AHA.55@cpmsnbbsa07>:
>I don't think that's what was meant. What I think was meant was to build
>a formatting around PGP, in such a way that when you unformat you get
>only the encrypted data of the length desired, and then building a OTP
>that gives the data you want/need it to give. This does several things,
>most importantly for most would be the fact that under RIP you could be
>forced to reveal a key that gives an accurate decryption to the
This idea of having the compressed encrypted data in a block
such that any key could work is easier than you might think
Matts BCIOM does that right know. So there is code to do that
only you have to convience the PGP people to allow a bijective
mode and I don't think the NSA would let them but something
like that in code that any one could use.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: ISO 9796-1:1991
Date: Tue, 8 May 2001 06:09:34 GMT
Uwe Guenther wrote:
> I have to implement an client that uses german HBCI-Protocol
> (HomeBankingComputerInterface). There are references to
> the ISO 9796-1:1991(formating and signing). Since this standard
> are withdrawn, there is no way to get the standard from ISO.
I doubt that that should be impossible -- there has to be some possibility
for checking up on old standards just to see what they said. Not necessarily
by the standard sales channels.
However, it is also an IEC standard, and judging from their
catalogue (at http://www.iec.ch) it appears possible to order it there.
As far as I can make out it has not been withdrawn from IEC, so don't
check the withdrawn radio box when you search for it.
--
Anders Thulin [EMAIL PROTECTED] 040-661 50 63
Telia ProSoft AB, Carlsgatan 6, SE-201 20 Malm�, Sweden
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Black & white .gifs?
Date: Tue, 08 May 2001 03:22:53 -0400
wtshaw wrote:
>
> In article <[EMAIL PROTECTED]>, Benjamin Goldberg
> <[EMAIL PROTECTED]> wrote:
>
> > Again we see how stego is generally vulnerable to active attacks.
>
> radiofreetexas.com/wts/pix/BWpenta.GIF is a picture of the pentagon in
> black and white pixels. There are several ways that this simple image
> can contain encrypted information stegnographically. However, steog
> may productively use obscurity, the best methods rely on not telling
> how it is done so even the presence of extra information is not
> tipped.
Sorry for the late reply, but... What do you mean by this last sentence
here?
IMHO, if a stego method X is "good," then if an opponent who suspects
than the image contains data encoded with X, there is no reliable way of
telling if X was used, even if the opponent knows the full details of X.
Suppose that there is data steganographically encoded in the image you
mention. Further suppose that I suspect method X was used. If the best
test I have to see if X was used is only accurate 50% of the time (ie,
if I might as well be flipping a coin), then X is a good method.
--
Shift to the left, shift to the right, mask in, mask out, BYTE, BYTE,
BYTE !!!
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RSA BRUTE FORCE
Date: Tue, 1 May 2001 10:59:44 -0700
I've found the flaw. Your method is still exponential, although a rather odd
exponential. In order to see this I moved to hex which is just the big
brother of binary. I found that for values that are close together this
works fairly quickly, but as the numbers get further apart the time grows
exponentially (after a few tweaks to not assume the numbers are the same
length). I also noted that the time required increased exponentially in the
length of the factors, and so also in the length of the value being
factored. So while it is a very good try, and certainly one of the better
amateur attempts (i.e. I won't compare it to NFS which is so far beyond
amateur as to be incomparable) I have seen. This is a good method of
factoring relatively small numbers, but the exponential puts it's maximum
effectiveness at well below 512-bits.
Joe
"Erictim" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> thanks for the replys. i don't understand enough about programming
languages
> to code a program and test this. if you see this in a newsgroup you may
need
> to set your preferences to accept larger messages.
> this is an example of the greater than,less than brute force attack i was
> referring to. this would result in probably not more than 40000 test
cases and
> i have heard that computers are fast when doing multiplication. sorry
about
> caps
>
> (0,0) (0,1) (0,2) (0,3) (0,4) (0,5) (0,6) (0,7) (0,8) (0,9)
> (1,1) (1,2) (1,3) (1,4) (1,5) (1,6) (1,7) (1,8) (1,9)
> (2,2) (2,3) (2,4) (2,5) (2,6) (2,7) (2,8) (2,9)
> (3,3) (3,4) (3,5) (3,6) (3,7) (3,8) (3,9)
> (4,4) (4,5) (4,6) (4,7) (4,8) (4,9)
> (5,5) (5,6) (5,7) (5,8) (5,9) chart 1
> (6,6) (6,7) (6,8) (6,9)
> (7,7) (7,8) (7,9)
> (8,8) (8,9)
> (9,9)
>
>
> (0,0)
>
(1,0)
> (1,1)
> (2,0) (2,1)
> (2,2)
> chart 2 (3,0) (3,1) (3,2) (3,3)
> (4,0) (4,1) (4,2) (4,3) (4,4)
> (5,0) (5,1) (5,2) (5,3) (5,4) (5,5)
> (6,0) (6,1) (6,2) (6,3) (6,4) (6,5) (6,6)
> (7,0) (7,1) (7,2) (7,3) (7,4) (7,5) (7,6) (7,7)
> (8,0) (8,1) (8,2) (8,3) (8,4) (8,5) (8,6) (8,7) (8,8)
> (9,0) (9,1) (9,2) (9,3) (9,4) (9,5) (9,6) (9,7) (9,8) (9,9)
>
> a junction is considered to be the pair of numbers resulting in a value
that
> is immediately greater than and less than the number being compared to.
>
> pairs are represented as (X, Y)
>
> chart 1
> find upper junction pair and do(X+1, Y-1)
> if the lower pair of the junction is in the far left
> column then take the upper junction pair and do(X+1, Y)
>
> chart 2
> find lower junction pair and do(X+1, Y+1)
> if upper junction pair is in the far right column
> then take the lower junction pair and do(X, Y+1)
>
>
> example
>
> X * Y = Z
> X * Y = 39772916239307209103
>
> 5999999999 * 5999999999 = too small
> 5999999999 * 6999999999 = too large
> (upper junction pair is (5,6))
> (lower junction pair is (5,5))
> by chart 1 take (5+1, 6) = (6,6)
>
> 6199999999 * 6399999999 = too small
> 6199999999 * 6499999999 = too large
> (1+1, 4-1) = (2, 3)
>
> 6249999999 * 6359999999 = too small
> 6249999999 * 6269999999 = too large
> (4+1, 6-1) = (5, 5)
>
> 6256999999 * 6355999999 = too small
> 6256999999 * 6356999999 = too large
> (6+1, 5+1) = (7, 6)
>
> 6257399999 * 6356099999 = too small
> 6257399999 * 6356199999 = too large
> (3+1, 1-1) = (4, 0)
>
> 6257489999 * 6356039999 = too small
> 6257489999 * 6356049999 = too large
> (8+1, 3+1) = (9, 4)
>
> 6257492999 * 6356046999 = too small
> 6257492999 * 6356047999 = too large
> (2+1, 7-1) = (3, 6)
>
> 6257493299 * 6356046099 = too small
> 6257493299 * 6356046199 = too large
> (2+1, 0+1) = (3, 1)
>
> 6257493329 * 6356046109 = too small
> 6257493329 * 6356046119 = too large
> (2+1, 0+1) = (3, 1)
>
> last digit must be 1, 3, 7 or 9, test them all and
> X = 6257493337
> Y= 6356046119
> 6257493337 * 6356046119 = 39772916239307209103
>
> example 2
> X * Y = 239812014798221
>
> 19999999 * 09999999 = too small
> 19999999 * 19999999 = too large
> (X, Y+1) = (1, 0+1) = (1,1)
>
> 14999999 * 14999999 = too small
> 14999999 * 15999999 = too large
> (4+1, 5) = (5,5)
>
> 15399999 * 15499999 = too small
> 15399999 * 15599999 = too large
> (3+1, 5-1) = (4,4)
>
> 15479999 * 15489999 = too small
> 15479999 * 15499999 = too large
> (7+1, 9-1) = (8,8)
>
> 15484999 * 15485999 = too small
> 15484999 * 15486999 = too large
> (4+1, 6-1) = (5,5)
>
> 15485799 * 15485899 = too small
> 15485799 * 15485999 = too large
> (7+1, 9-1) = (8,8)
>
> 15485859 * 15485869 = too small
> 15485859 * 15485879 = too large
> (5+1, 7+1) = (6,6)
>
> last digit is 1, 3, 7 or 9
> X=15485863
> Y=15485867
> 15485863 * 15485867 = 239812014798221
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm
Date: Tue, 1 May 2001 11:19:24 -0700
There are no known usable flaws in Rijndael/AES. The NSA did not choose
Rijndael to be AES, NIST did. This is an important distintion because NIST
is in charge of setting requirements for government agencies, NSA is in
charge of brutalizing the security of all other countries and supplying
ciphers to us (meaning the US) that are not subject to brutality. The
relatively short key in Rijndael is also not an issue, simply do the math.
You have in front of you a machine that can do certainly no more than 2
billion additions per second. Let's say that it only takes one addition to
encrypt with Rijndael (which it doesn't it actually takes much more), that
means that 32-bit crypto can be broken in 2 seconds, 64-bit in 8 billion
seconds. But even with 1 billion billion of these machine working 24 hours a
day it would take 20,000 years to break 128-bit cryptography. To break
256-bit cryptography with 1 billiob billion billion billion of those
machines would take 400,000,000 years. I don't believe the short key is a
major issue.
More of an issue would be the potential for design flaws. Like Tom pointed
out several rounds have been broken. If you are concerned about that there
is no reason that you can't add on a few rounds. If you want to be very
paranoid move to 3AES, that's where you choose 3 keys of either 128, 192, or
256 bits. Use the first key to encrypt with AES, second to decrypt, and the
third to encrypt. This should give something approximetely equivalent to
Rijndael with 3x the rounds. Rijndael was designed extremely well, it's
small size is a result of large amounts of knowledge about cryptographic
algorithms, and does not weak it. It's relatively high speed does not
detract from it's security, in fact speed of encryption and decryption has
very little to do with the security, the only concern is the speed of
not-allowed decryption. I would not say that Rijndael is the strongest
algorithm, primarily because we have some evidence that Serpent and Twofish
are probably marginally stronger, but I do believe that for the next several
years it is very secure.
Joe
"Ryan M. McConahy" <[EMAIL PROTECTED]> wrote in message
news:3aedc92b$0$88181$[EMAIL PROTECTED]...
> Since there are some major flaws with AES, such as it was designed to be
> small, not necessarially to encrypt to the max, and since the NSA chose
it,
> what would you say is the strongest algorithm, other than an OTP?
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Intacta.Code ...
Date: Tue, 1 May 2001 11:27:17 -0700
I have stayed out of this for a while, because you seemed to at least have
the decency to only include Tom in your (honestly quite childish) attacks.
However you have obviously decide that anyone who replies to you is
inadequate. maybe you're compensating for some personal lacking? Let me
guess you want a Corvette? that's just so perfectly Freudian. I suppose for
once your attacks make you feel like a "big" man?
Joe
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
------------------------------
From: [EMAIL PROTECTED] (Snot)
Subject: Re: IV question !!
Date: Tue, 08 May 2001 07:51:06 GMT
On Mon, 7 May 2001 08:44:06 +0200, "gilles" <[EMAIL PROTECTED]>
wrote:
>hello,
>
>i have a stream cipher
>when i encrypt a file
>i put the IV in this file
>if a person modify some
>bit of this IV my file
>is unrecoverable !!!
>
>i seek some possibility for
>avoid that
>
>i have some idea
>duplicate the IV or store it
>in another file
>create a counter IV (not alea)
>what is the best way
>thanks !!
>
A counter IV may be reasonable
but if the data is available to be
accessed by an attacker then
you must use other methds to
protect it.
Within the limitations of a stream
cipher, you cannot protect the
file from being damaged, but the
protection may be very strong,
so the attacker will not breach
the data.
So, if the data is critical, then you
must have a backup, either on
tape or CD-R or CD-RW or other
dependable media, and you
need to keep it safe. That way
you will have a source for the
undamaged IV's and the data
itself. This should be pretty
obvious, no?
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Steganographic idea.
Date: Tue, 08 May 2001 03:55:40 -0400
If someone has suggested this idea before, please tell me.
First, get a grayscale image, with each pixel in the range 0..255.
Then, get a CSPRNG which can efficiently produce a byte at a time.
The output image is a black and white picture, made up of dots.
The recipient must know both the original picture, and the PRNG seed.
for each pixel in the inputted grayscale image:
threshhold := CSPRNG.nextbyte();
if( pixel < threshhold || pixel = 0 ) output( whitepixel )
if( pixel > threshhold || pixel = 255 ) output( blackpixel )
if( pixel = threshhold && pixel != 0 && pixel != 255 )
if( datatohide.nextbit() = 0 )
output( whitepixel )
else
output( blackpixel )
This kind of lossy compression will result in an image which is still
recognizable, and which can pack down to 8 pixels a byte, trivially.
--
Shift to the left, shift to the right, mask in, mask out, BYTE, BYTE,
BYTE !!!
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Tue, 08 May 2001 09:52:31 +0200
James Felling wrote:
>
> If you assume a fixed permutation( i.e. agreed upon at start) you are neither better
> nor worse off than not massaging your data.
Let me repeat what I said previously in this thread. I
denote three segments of OTP by S1, S2 and S3 and three
messages by M1, M2 and M3. I have 6 possible permutions.
I ask: If I send the messages using the first permutation,
is it secure? ......... In all, I ask 6 times and get 6
answers. Do you think that there will be differences?
If yes, on what these differences are based? Note that
I don't yet have any FIXED permutations. I haven't
sent the messages and am currently free to decide. (Maybe
I am trying to find out the best permutation of the 6, in
case there is indeed a competent person to answer my
questions -- though certainly I very very much doubt that.)
M. K. Shen
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Tue, 08 May 2001 01:48:07 -0700
Mok-Kong Shen wrote:
>
> James Felling wrote:
>
> > If you assume a fixed permutation( i.e. agreed upon at start)
> > you are neither better nor worse off than not massaging your data.
>
> Let me repeat what I said previously in this thread. I
> denote three segments of OTP by S1, S2 and S3 and three
> messages by M1, M2 and M3. I have 6 possible permutions.
> I ask: If I send the messages using the first permutation,
> is it secure? ......... In all, I ask 6 times and get 6
> answers.
You have gotten good-to-excellent explanations from Skala,
Schlyter and Felling. I recommend you re-read what they
wrote, from Skala's first response to you in the this
strand. They did understand your questions; some of your
questions do not have answers of the form you expected.
> Do you think that there will be differences?
> If yes, on what these differences are based?
None of the permutations are intrinsically better or worse
than than the others, but the process by which you choose
one can spoil perfect secrecy. This is at its core the same
issue as "random" being a property of a generator and not a
particular sequence of bits.
> Note that
> I don't yet have any FIXED permutations. I haven't
> sent the messages and am currently free to decide. (Maybe
> I am trying to find out the best permutation of the 6, in
> case there is indeed a competent person to answer my
> questions -- though certainly I very very much doubt that.)
There is no best or worst permutation to choose; only good
and bad methods by which to make the choice. Specifically,
you lose perfect secrecy if the selection of the permutation
is based, in whole or in part, on the content of the
keystream segments that you are permuting. Matthew Skala
stated this more formally as the requirement for
independence. It is the point behind Paul Schlyter's
byte-sorting example. It is what James Felling has been
explaining.
--Bryan
------------------------------
From: yomgui <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Tue, 08 May 2001 10:00:00 +0100
free, small, cross platform, safe, simple, fast, open source,
symmetric stream and file encryption
http://bigfoot.com/~kryptyomic
Frank Uepping wrote:
>
> Hi,
> I am new with en/decryption and I am looking for a free and open
> en/decryption C/C++ library that compiles with gcc and C++ Builder.
>
> Thanks
> Frank U.
--
���g��
oim 3d - surface viewer - http://i.am/oim
kryptyomic - encryption scheme - http://bigfoot.com/~kryptyomic
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
Date: Tue, 08 May 2001 11:16:45 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
>
> > To avoid unnecessary discussions, I like to cite the following
> > from my answer to Bryan Olson of Mon, 16 Apr 2001 13:22:17 +0200:
> >
> > I like to add something to make my last paragraph better
> > understandable: If one of the streams gets a factor 1.0
> > (and it is uniform), isn't that everything is again
> > (rigorously) theoretically o.k. in that particular issue?
>
> And the answer was:
>
> | Of course not. The theorem was:
> | | as long as the streams are independent, if any of the
> | | streams are uniform then the sum is uniform.
>
> The modified method only guarantees uniformity when a particular
> stream is uniform. If have a single random stream known to be
> uniform then there's no point in the combining scheme at all.
> The W-H scheme doesn't require that you know how good each stream
> is. As long as they're independent, the result will be at least
> as good as the best of them. In realistic cases we expect the
> result to be better than the best of them.
>
> The problems I noted are only loosely related to Gladman's work.
> When I talk about a uniform sequence, I'm not just talking about
> the individual values being uniform; I mean the entire sequence
> so each values must also be independent of the list of
> predecessors.
I put the above quote in order to correct my neglecting
the '1.0' in connection with 'uniform'. If you look back
at our previous discussions you would find that I said at
one point that I implicitly assumed that the streams are
independent. In fact, if I use a number of PRNGs, I have
no 'practical' means to verify that they are independent
at all, if I don't err. (Actually I even believe that no
set of PRNGs are, or can be shown to be, (theoretically)
absolutely independent, though I doubt that I could prove
that belief.)
As I also mentioned previously, Brian Gladman did perform
a theoretical study. He employed thereby independent ideal
random variables. He has thus covered both the theoretical
and the experimental aspects of the present issue.
(BTW, I certainly recognize the big importance of being
everywhere rigorously exact/complete in one's statements,
though 'relaxations' are occassionally to be found even
in published stuffs, for convenience or due to neglection.
Rather ironical in this connection appears to be the
(chance) fact that the seminal paper by Wichmann and Hill
in Appl. Stat. didn't contain the word 'independent' or
'indenpendence' at all.)
M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (Joe H Acker)
Subject: Question about randomness and OTPs
Date: Tue, 8 May 2001 11:19:59 +0200
Hi!
There's still one thing I don't understand about OTPs. Maybe someone can
point in the right direction. Here's my question:
If I XOR the random data with my plaintext, the resulting ciphertext
will have the same (maximum) entropy than the random data. Is that
correct?
If that's correct, then I don't understand why I cannot use the
ciphertext to encrypt another plaintext with it, and so on.
I suppose the answer why this won't work is trivial and similar to the
explanation why re-using an OTP is insecure. Could anyone explain this a
little bit further to me?
Thanks,
Erich
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Tiny s-boxes
Date: 8 May 2001 09:32:35 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I don't follow ya. GOST, Rijndael, Twofish, Square, etc can be done either
> as 8x8's (or 4x4s for GOST) or as a set of 8x32's...
Twofish can also be implemented using a pair of 4x4 S-boxes. You
probably wouldn't want to do this, though.
Interestingly, small S-boxes are making something of a comeback in
bitslice block ciphers. Noekeon, a new cipher by Daemen, Peeters, Van
Assche and Rijmen and submitted to the NESSIE project, uses a single
self-inverse 4x4 S-box.
The advantage of bitslice designs appears to be that the diffusion
layers can be simpler and more efficient because they're performed
`side-on' to the nonlinear subsitutions. This is great for wide-trail
devotees (like me).
I think the future holds good things for bitslice ciphers, and hence for
small S-boxes.
-- [mdw]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Tue, 08 May 2001 11:44:32 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> >
> > James Felling wrote:
> >
> > > If you assume a fixed permutation( i.e. agreed upon at start)
> > > you are neither better nor worse off than not massaging your data.
> >
> > Let me repeat what I said previously in this thread. I
> > denote three segments of OTP by S1, S2 and S3 and three
> > messages by M1, M2 and M3. I have 6 possible permutions.
> > I ask: If I send the messages using the first permutation,
> > is it secure? ......... In all, I ask 6 times and get 6
> > answers.
>
> You have gotten good-to-excellent explanations from Skala,
> Schlyter and Felling. I recommend you re-read what they
> wrote, from Skala's first response to you in the this
> strand. They did understand your questions; some of your
> questions do not have answers of the form you expected.
>
> > Do you think that there will be differences?
> > If yes, on what these differences are based?
>
> None of the permutations are intrinsically better or worse
> than than the others, but the process by which you choose
> one can spoil perfect secrecy. This is at its core the same
> issue as "random" being a property of a generator and not a
> particular sequence of bits.
>
> > Note that
> > I don't yet have any FIXED permutations. I haven't
> > sent the messages and am currently free to decide. (Maybe
> > I am trying to find out the best permutation of the 6, in
> > case there is indeed a competent person to answer my
> > questions -- though certainly I very very much doubt that.)
>
> There is no best or worst permutation to choose; only good
> and bad methods by which to make the choice. Specifically,
> you lose perfect secrecy if the selection of the permutation
> is based, in whole or in part, on the content of the
> keystream segments that you are permuting. Matthew Skala
> stated this more formally as the requirement for
> independence. It is the point behind Paul Schlyter's
> byte-sorting example. It is what James Felling has been
> explaining.
I continue to think that the claim 'there is no best
or worst permutation to choose' logically implies
'any choice is equivalent to the other' and hence the
choice is entirely free, much like e.g. when deciding
to buy a certain book in a store I can pick at my will
any one copy of the same book on the shelf. (I might
habitually try to always pick the 3rd copy, if there
are at least three copies, because, for example, the
number 3 has something to do with my birthday, but
does it really matter?)
M. K. Shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Ciphertext only
Date: Wed, 2 May 2001 15:59:31 -0700
It makes sense under certain circumstances. However it also requires certain
additional knowledge, in particular which cipher was used. However the
answer about whether or not it is possible depends heavily on the cipher in
question. For example with DES, if you can afford to burn 2^56 bits of RAM
you can break DES with ~2^48 effort, without knowing a single plaintext
value. A Vigenere cipher can be broken with generally much smaller amounts
of information (the actual value is key size dependent). Breaking 3DES using
a only ciphertext requires close enough to the entire code book as to be
irrelevant. Breaking Enigma (WWII germany) using ciphertext only can be done
fairly easily. Going to more esoteric definitions of cipher linguistics is
in part the study of analyzing languages given no cheat shete to begin with,
so it also may be considered.
Assuming you mean modern ciphers, the answer is almost certainly, it is
possible, but you don't want to do it.
Joe
"Kris Reyes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Can someone please explain how or direct me to sources which can tell me
> how, given the ciphertext, one can obtain the key.
>
> Is this even possible, feasible?? Does this even make sense??
>
> Thanks for any help in advanced.
>
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: free en/decryption library
Date: 8 May 2001 10:08:14 GMT
Frank Uepping <[EMAIL PROTECTED]> wrote:
> I am new with en/decryption and I am looking for a free and open
> en/decryption C/C++ library that compiles with gcc and C++ Builder.
http://directory.google.com/Top/Science/Math/Applications/
Communication_Theory/Cryptography/Programming_Libraries/
That wasn't so hard, now, was it?
-- [mdw]
------------------------------
** 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
******************************
