Cryptography-Digest Digest #215, Volume #12 Wed, 12 Jul 00 22:13:01 EDT
Contents:
Re: Efficient Arithmetic Coding ("Joseph Ashwood")
Re: Steganographic encryption system (jungle)
Re: Efficient Arithmetic Coding (SCOTT19U.ZIP_GUY)
Re: Efficient Arithmetic Coding (David A Molnar)
Bit Shuffling (Jayant Shukla)
Re: RC4-- repetition length? ([EMAIL PROTECTED])
Re: bank vault security (was Re: SecurID crypto (was "one time passwords and
RADIUS")) (Eric Smith)
Re: Diffie Hellman Primes : Speed Tradeoff Q (David Hopwood)
Re: Bit Shuffling ("Trevor L. Jackson, III")
Re: Compression & Encryption in FISHYLAND (Tim Tyler)
Re: Random Numbers (John Savard)
Re: Newbie Question (long-ish) ("Trevor L. Jackson, III")
Re: Steganographic encryption system (Michael Rozdoba)
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Efficient Arithmetic Coding
Date: Wed, 12 Jul 2000 15:31:17 -0700
I'm sorry, but that's a dumb post, even for you.
This was not a discussion of compression, encryption, or "Matts" (whatever
that is), or anything else that your words could possibly have meaning for.
Joe
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> If you look at my compression page it has a pointer
> to Matts. Which is good in the sense that it compresses
> with out gaps. It compresses to the complete set of possible
> binary files and is totally bijetive as far as I can tell.
[snip spam length signature]
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Wed, 12 Jul 2000 18:43:34 -0400
phil hunt wrote:
>
> On Wed, 12 Jul 2000 00:40:39 -0400, jungle <[EMAIL PROTECTED]> wrote:
> >current, well working stego have ration of 1 to 2 ...
> >and all are super safe / super stego ...
> >you are creating stego that will have ratio of 1 to 30 ...
> >
> >what a waste of resources ...
>
> I'm not forcing you to use it, you know.
I'm not stopping your from developing un - needed software, to ...
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Efficient Arithmetic Coding
Date: 12 Jul 2000 23:15:10 GMT
[EMAIL PROTECTED] (Joseph Ashwood) wrote in <O76ntDF7$GA.318@cpmsnbbsa08>:
>I'm sorry, but that's a dumb post, even for you.
>This was not a discussion of compression, encryption, or "Matts"
>(whatever that is), or anything else that your words could possibly have
>meaning for.
> Joe
>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> If you look at my compression page it has a pointer
>> to Matts. Which is good in the sense that it compresses
>> with out gaps. It compresses to the complete set of possible
>> binary files and is totally bijetive as far as I can tell.
>[snip spam length signature]
>
>
>
Actually it was a thread about efficient Arithmetic Coders in
C or C++. What Matt has is a nice Arithmetic Coder in C++
so it was on post. I don't remeber has web address but my
compression pages have pointers to it. So that my presence
is to offensive to you. But thats to bad!!
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed ** JavaScript OK**
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Efficient Arithmetic Coding
Date: 12 Jul 2000 23:09:04 GMT
Joseph Ashwood <[EMAIL PROTECTED]> wrote:
> I'm sorry, but that's a dumb post, even for you.
> This was not a discussion of compression, encryption, or "Matts" (whatever
> that is), or anything else that your words could possibly have meaning for.
> Joe
Is arithmetic coding was a kind of compression?
Seems to depend on how you read the subject, either as
"efficient arithmetic" coding, or efficient "arithmetic coding."
-David
------------------------------
From: [EMAIL PROTECTED] (Jayant Shukla)
Subject: Bit Shuffling
Date: 12 Jul 2000 23:39:25 GMT
In a previous post Mok-Kong talked about the
fact that transposition is poorly supported
by processor instructions. He also suggested
that future processors should have an
instruction that will facilitate arbitrary
shuffle of bits in the data block.
The main reason for not supporting or using
the shuffle operation is the fact that we do
not have an efficient method to generate an
arbitrary shuffle using a "small" enough key.
The shuffling can performed by using an NxN
matrix and that requires N^2 elements.
I will demonstrate a method to shuffle an
N-bit data block using an N-bit key. This
operation is reversible. I also presented this
last year at the Crypto '99 rump session.
The hardware implementation of this method is
_really_ tiny, and fast.
enjoy!
~Jayant
TRLOKOM
p.s.: I have a patent pending on this.
SHUFFLE
=======
Original block : a b c d e f g h i j
Key : 1 0 1 1 1 0 0 1 0 1
Block 1 : a c d e h j
Block 2 : b f g i
New Block : a c d e h j b f g i
The bits from the "Original block" are
moved to "block 1" if the corresponding
key bit is "1" and to "Block 2" if the
corresponding key is "0".
The new block is formed by concatenating
the "Block 1" and "Block 2" together.
UNSHUFFLE
=========
1) Count of number of "1s" (=n1) in the key.
2) Split the data block into two blocks
by placing the first n1 bits into "Block 1"
and remaining bits into "Block 2".
3) Loop over all key bits (left to right)
if the key bit is "1" move the bit from
"Block 1" to the "New Block" and if it
is zero them move the bit from the
"Block 2" to the "New Block".
Key : 1 0 1 1 1 0 0 1 0 1
this gives n1 = 6;
original block : a c d e h j b f g i
^
|
split here
Key : 1 0 1 1 1 0 0 1 0 1
Block 1 : a c d e h j
Block 2 : b f g i
Block 1 : a c d e h j
(occupy '1' pos)
Block 2 : b f g i
(occupy '0' pos)
New Block : a b c d e f g h i j
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4-- repetition length?
Date: Wed, 12 Jul 2000 23:48:31 GMT
In article <[EMAIL PROTECTED]>,
John Myre <[EMAIL PROTECTED]> wrote:
> Bill Unruh wrote:
> <snip>
> >
> > Since 16^2*16!= 10^16, your cycles must all have been much much
shorter
> > than that!. Has any work been done on analysing the cycles of RC4?
>
> RSA did a lot of analysis, but declines to make it public (at least,
> the last I know of). Somewhere at their site there may be more
> recent information.
>
> > Is
> > there some way of changing it to ensure that there is only one
cylce of
> > max length?
>
> I don't know, but my intuition tells me "no, at least not without
> major rework." And of course, even minor rework will usually
> invalidate prior analysis. Somebody smarter than me would have
> to find this question interesting enough to work on; I can't see
> where to start.
>
> It would be interesting to see RSA's analysis of cycle lengths.
> What guarantees on minimum cycle length are there? What are the
> statistics on expected cycle lengths? And so forth. From a
> practical point of view, we don't need maximal length, just
> very long. And with 256^2 x 256! states, there is sure a lot
> of room.
>
> JM
>
I did some analysis a few years ago because RC4 resembled a
generator I had developed independently. Here's the analysis:
http://burtleburtle.net/bob/rand/isaac.html
Here's a cut-n-paste of an interesting relevant paragraph:
For every sequence that can be produced by RC4, there are 256 internal
states that produce the same sequence of x+y mod 256. If
(m[0..255]=m_0..m_255,a,i) are one such state, then
(m[0..255]=m_n..m_((n+255) mod 256), (a-n) mod 256, (i-n) mod 256) is
another such state. (These equivalent states were first noted by Paul
Crowley on sci.crypt.) Although x+y mod 256 is the same for each such
sequence, m[x+y mod 256] (the reported result) will be different for
each such sequence. The 256 such sequences will have the same length. A
single cycle may contain 1, 2, 4, 8, 16, 32, 64, 128, or 256 such
equivalent sequences, in which case there will be 256, 128, 64, 32, 16,
8, 4, 2, or 1 such cycles. For example, the short cycles mentioned
earlier pass through a sequence of 255 values before mapping to an
equivalent of the starting state -- all 256 equivalents of the starting
state are on one cycle, so each short cycle is 255*256 values long.
- Bob Jenkins
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Subject: Re: bank vault security (was Re: SecurID crypto (was "one time passwords
and RADIUS"))
Date: 12 Jul 2000 17:50:00 -0700
I wrote:
> With crypto algorithms, it is generally advantageous to make the details
> public, because you want to encourage cryptanalysis *before* you deploy
> a gazillion instances of the algorithm. But the bank vault is (or at
> least can be) unique. Making the *exact* design of the vault available
> for public scrutiny is unlikely to turn up any vulnerabilities that
> aren't just as easily found with a model that is generally similar but
> different in the details. Whereas with crypto algorithms, those details
> can be critical to the security.
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> writes:
> I think this comparison is apples v oranges.
Yes. That's my point. Someone else compared crypto algorithms to bank
vaults, and I was specifically trying to point out that it is a very
flawed analogy.
------------------------------
Date: Wed, 12 Jul 2000 22:23:10 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
=====BEGIN PGP SIGNED MESSAGE=====
Mark Wooding wrote:
> Anton Stiglic <[EMAIL PROTECTED]> wrote:
>
> > Yes this is was first described by van Oorschot and Wiener, in a
> > Eurocrypt 96 paper. It generalizes to using p = Rq + 1 (an attacker
> > will have to test R values). It's a good indication that one should
> > work in the subgroup of order q.
>
> It extends to the case where R is a smooth composite too, I think.
>
> > Lim-Lee primes, primes of the form p = 2*q_1*q_2*...*q_n + 1, where
> > the q_i's are large work fine. You can simply work in one of the
> > subgroups of large prime order.
>
> That only partially answers my question. Do we have a problem if we do
> arithmetic mod p = q R + 1, where q is a large-ish prime, p is large,
> and R is a random composite (therefore possibly having small factors,
> but also likely to have fairly large ones), and work in the subgroup of
> order q?
Yes. See van Oorschot and Wiener's paper:
Paul C. van Oorschot, Michael J. Wiener,
"On Diffie-Hellman Agreement with Short Exponents,"
Advances in Cryptology - EuroCrypt '96.
Basically it's possible to combine the information gained from each small
factor of the order, and use that to help in an attack on the main
problem. It's sufficient for security that all the factors are > q,
but if q is about 200 bits, say, there's no easy way to check that the
factorisation of R satisfies this condition without making R prime.
Anyone implementing Diffie-Hellman-based protocols should definitely read
both the above paper, and
Chae Hoon Lim, Pil Joong Lee,
"A Key Recovery Attack on Discrete Log-Based Schemes using a
Prime Order Subgroup,"
Advances in Cryptology - Crypto '97.
(which recommends the same thing as the EuroCrypt '96 paper, but gives
additional reasons for it). Don't rely just on summaries from this
newsgroup - including mine. If you can't find copies of the above papers
in a library, I thoroughly recommend the Springer-Verlag CD-ROM that has
Crypto and EuroCrypt papers from 1981 to 1997 in PDF format.
- --
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
iQEVAwUBOWzhaTkCAxeYt5gVAQH6kAf/Q4uZ9zMHvrgjqBSMC3BYoBft1HI4ToB+
mqjvGAuWYMA8JhjN+eIWghl8MBvMPXFTiwR8+/sfTuTnesXda5uZFsJGm+E+RONf
e/VW4a2eKmmm5a7jeQrwa9TCg1pPRcCzoJRYuakO4D+uFJZvX8okL/1euWyYdKT/
ZA7byYKkhbPrpx0YDwXnwlVod08VyvhRXdThjGQMthX5fUzaVbKfT+zrr1BM5fSo
qalQs72sg91708UMQqqTDLm70BhzAUVST6dRoSr8ddkKYgT5UEIwQngJTTgLJs5j
jsz+AIE5UzJQwS8sMQfOZnJQxCzpRwIc/QV/oxOg93+Dfz3wTfoixA==
=7wyI
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 12 Jul 2000 21:23:58 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Bit Shuffling
This is far from effective. The inadequacy of the keying is visible in the
fact that there are only 2^N keys which is dwarfed by the number of
permutations reachable with a real shuffle -- N!. The distribution of the
subset is also bad, almost pathologically so, in that the elements sorted by
the selection process remain in sequence.
In this regard the algorithm is reminiscent of a single quicksort pass. To
actually shuffle with this mechanism one would need log N passes for a total
of N log N keying bits.
Since this algorithm also needs 2 N space, it may be more efficient to use the
classic in place shuffle, dealing with individual bits rather than
memory-addressable elements.
Jayant Shukla wrote:
> In a previous post Mok-Kong talked about the
> fact that transposition is poorly supported
> by processor instructions. He also suggested
> that future processors should have an
> instruction that will facilitate arbitrary
> shuffle of bits in the data block.
>
> The main reason for not supporting or using
> the shuffle operation is the fact that we do
> not have an efficient method to generate an
> arbitrary shuffle using a "small" enough key.
> The shuffling can performed by using an NxN
> matrix and that requires N^2 elements.
>
> I will demonstrate a method to shuffle an
> N-bit data block using an N-bit key. This
> operation is reversible. I also presented this
> last year at the Crypto '99 rump session.
>
> The hardware implementation of this method is
> _really_ tiny, and fast.
>
> enjoy!
>
> ~Jayant
> TRLOKOM
>
> p.s.: I have a patent pending on this.
>
> SHUFFLE
> -------
>
> Original block : a b c d e f g h i j
>
> Key : 1 0 1 1 1 0 0 1 0 1
>
> Block 1 : a c d e h j
>
> Block 2 : b f g i
>
> New Block : a c d e h j b f g i
>
> The bits from the "Original block" are
> moved to "block 1" if the corresponding
> key bit is "1" and to "Block 2" if the
> corresponding key is "0".
>
> The new block is formed by concatenating
> the "Block 1" and "Block 2" together.
>
> UNSHUFFLE
> ---------
>
> 1) Count of number of "1s" (=n1) in the key.
> 2) Split the data block into two blocks
> by placing the first n1 bits into "Block 1"
> and remaining bits into "Block 2".
>
> 3) Loop over all key bits (left to right)
> if the key bit is "1" move the bit from
> "Block 1" to the "New Block" and if it
> is zero them move the bit from the
> "Block 2" to the "New Block".
>
> Key : 1 0 1 1 1 0 0 1 0 1
>
> this gives n1 = 6;
>
>
> original block : a c d e h j b f g i
> ^
> |
> split here
>
> Key : 1 0 1 1 1 0 0 1 0 1
>
> Block 1 : a c d e h j
> Block 2 : b f g i
>
> Block 1 : a c d e h j
> (occupy '1' pos)
>
> Block 2 : b f g i
> (occupy '0' pos)
>
> New Block : a b c d e f g h i j
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression & Encryption in FISHYLAND
Reply-To: [EMAIL PROTECTED]
Date: Wed, 12 Jul 2000 23:39:56 GMT
Kurt Shoens <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
: [...] If encrypting once is good, surely encrypting twice, three times,
: or N-times is better?
Though in principle it's unlikely to be the best way to use the available
keyspace, super-encryption seems to me to be a practical method of
increasing security - if larger key spaces are available.
: And further: if we don't know how a cryptosystem will be attacked,
: then how do we defend it? Maybe 1-1 compression makes some unknown
: attack easier!
This has been claimed for chosen plaintext attacks. If not every file is
a valid compressed file, this may make choosing some particular inputs to
the cypher impossible.
:>8-bit keys can be quite satisfactory - *if* both you and the opponent
:>know you're only ever likely to want to send 256 different messages.
:>In essence, you can number the messages, and then use a OTP.
: If you can use a one-time pad, none of this is worth worrying about.
It was hoped that this was an example of the uncompressed messages being
longer than the key - but the compressed ones being of a comparable size.
I.e. a case where compression brings the message length within the unicity
distance.
:>These measures can help defend against the possibility that the office
:>the messages are sent from is being bugged, or a huge number of other
:>possible security leaks.
: 1-1 compression doesn't help in these cases. If my office is bugged,
: why can't They (you know, Them) get the plaintext or at least the
: whole key?
Because (for example) of noise. I believe an embassy in London was once
bugged by bouncing a signal off a window and observing the vibrations
transmitted there from the golf-ball typewriter in the office, and
determining the messages from the ball's rotation times. I doubt this
technique always allowed perfect reconstructions.
Just because you have some sort of bug, that doesn't mean it gives you all
the information you would like.
: Let me ask you, what would you give up to use 1-1 compression? Would
: you accept a smaller key size? What you choose to use ECB mode?
: Would you use a less-studied algorithm? Accept a poorer random
: number generator? Forego some time outside on a nice day?
I've described it as "icing on the cake". I would not /want/ to give up
anything.
I can't really give a sensible answer to the question. It depends on how
much my data's worth, who I expect my attackers to be, how long the
messages are what my attackers are likely to know about them, the
probability of various kinds of compromise, etc.
In practice - as there are not yet a large number of 1-1 engines -
it /may/ currently be necessary to give-up something compression ratio to
get the 1-1 property. I've discussed if and when this is a good idea in
the past.
: In reality, there's no need to give up any of these things; I'm
: wondering how you rank 1-1 compression relative to all the other
: available security measures.
: You've pointed out that errors in implementation or operation can
: leave one exposed. I say let's focus our efforts on the correct
: use of known good techniques rather than diverting our attention
: to measures that don't really help.
It depends on the application:
If you've been told by your boss to get an encryption package together by
Monday morning, you can probably forget about compression.
If you're writing and marketing a program with large numbers of expected
users, and plenty of testing budget, you may be using a compression
program anyway. If you're doing that, it would be nice to get it right.
Using a poor compression program is one of the "implementation errors"
that could result in unnecessary exposure of one's data.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Random Numbers
Date: Thu, 13 Jul 2000 01:19:22 GMT
On Wed, 12 Jul 2000 09:52:32 -0700, "Paul Pires" <[EMAIL PROTECTED]>
wrote, in part:
>Could I impose on you to elaborate?
In general, yes. In this case, I thought I elaborated earlier in the
thread.
Essentially, the idea is:
If I have values that I know are random, uniformly distributed, but in
the wrong range, then to get them to the right range, I do this:
1) Accumulate enough of those values so that (wrong range)^n >= right
range.
2) Then, having a wrong range that is larger than the right range,
divide it into a multiple of the right range, and a remainder.
3) Take the range that is a multiple of the right range; accept those
values.
The secret of avoiding skipped values - not completely, but reducing
their number - is this:
when we have values PAST the right range, they belong to a new range.
Treat these as random numbers belonging to the wrong range, and apply
the same principle to them.
and if we have a multiple of the right range, then when we do generate
a number, we also have additional information, which of the possible
representations was used, and that too can be used as a new wrong
range.
I've put up an explanation and an example of this at
http://home.ecn.ab.ca/~jsavard/crypto/mi060305.htm
on my home page under "Keystream Base Conversion", based on my earlier
post in this thread.
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Wed, 12 Jul 2000 21:34:21 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Newbie Question (long-ish)
Stephen,
You don't need feedback on this cipher, you need a book on the fundamentals of
cryptography. Try "The Codebreakers" (historical perspective) and "The Handbook
of Applied Cryptography" (modern technology).
Stephen Hui wrote:
> Joseph Ashwood wrote:
> >
> > Actually this is in the FAQ. Basically the general concensus is that if your
> > program needs to remain secure to make the cipher secure, then your cipher
> > is not secure. Your software will be broken (see any warez site for
> > reference), your code will be known, and your security will never have
> > existed. So we would prefer you don't post your ciphertect here unless you
> > have an algorithm to go with it.
> > Joe
> >
>
> Duly noted; thanks. BTW, is there a URL or some other resource for the
> FAQ? I'd like to look over it.
>
> I'll think some more about my algorithm. Maybe there is a way to make
> it more secure....
>
> In fact, maybe someone can offer some ideas. I developed this algorithm
> three years ago, right after my freshman year of college (I'm now a
> 5th-year senior in Computer Science). Here's the general idea of my
> algorithm (mind you, I haven't had any formal training in cryptography
> or anything of that sort, but that's about to change in about six weeks
> when classes start up again):
>
> It was originally designed to be a one-way hash, but in the latest
> revision, I decided to try to make it two-way. It's the two-way feature
> that makes it insecure.
>
> [Note: When I mention "xor-ing letters", I mean xor-ing the letters'
> ASCII codes.]
>
> I can't remember the exact algorithm from the original design, but in
> general, it computed two keys based on the string (typically a password)
> that it is given. Then it goes through the string letter by letter,
> xor-ing the first key with even-indexed letters (suppose the string is
> represented as an array of characters) and xor-ing the second key with
> the odd-indexed letters. Then the ASCII code of the encrypted letter is
> shifted into the special-characters region of the ASCII codes (meaning
> an integer is added to the ASCII code of the encrypted character to
> yield a character that is not alpha-numeric, e.g. the console "graphics"
> characters). This is to keep the password file non-human-readable.
> There was a way to actually *encrypt* the key into the ciphertext, but I
> can't remember how that was accomplished.
>
> I did this to try to prevent a one-to-one mapping from plaintext letters
> to ciphertext letters. Any one letter would have to always fall into an
> even- or odd-index for this one-to-one mapping to occur.
>
> In the latest incantation, a two-way version of the algorithm, the
> unencrypted keys are prepended to the encrypted string. So it only
> works if the attacker doesn't know the algorithm.
>
> Each plaintext letter is still xor-ed with a key, but now, it's xor-ed
> with two keys. A string of letters is randomly generated (any length),
> and each adjacent pair of letters in the random string forms the two
> keys. For example, if my plaintext string is "text", and my random
> letter string is "dhvg", then the possible pairs of letters from the key
> string are dh, hv,vg, gd, dh, hv.... So each letter in the plaintext
> ("text") is xor-ed:
>
> "t" ^ "d" ^ "h" = encrypted "t"
> "e" ^ "h" ^ "v" = encrypted "e"
> ...
>
> If more random letters are used, the algorithm can map more ciphertext
> letters from a plaintext letter.
>
> It's not an effective hash since the keys are generated randomly, but
> prepending the random string to the ciphertext string allows the
> ciphertext to be decrypted easily because the algorithm (or attacker)
> can know where and how long the random string is.
>
> These algorithms are essentially letter-replacement, but a little more
> complex than the standard cereal-box-decoder-ring.
>
> Am I sort of on track, or am I totally out in deep roving left field?
> If anyone needs source code, I can provide sources for both (the first
> version is in Pascal and the second is in Perl5). Any ideas or comments
> will be greatly appreciated. I'm totally open any ideas.
>
> Thanks!
> Stephen.
------------------------------
From: Michael Rozdoba <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Thu, 13 Jul 2000 02:17:07 +0100
In article <[EMAIL PROTECTED]>, phil hunt
<[EMAIL PROTECTED]> wrote:
> >Any idea when you might have some code for us to play with?
> About the weekend, I expect.
That soon :)
[Snip]
> >As a newbie to linux, how easy will it be to extract files & then pass
> >them on to another process (such as a thumbnail viewer, mp3 player
> >etc), guaranteeing that the data doesn't pass through storage on disc
> >in an unencrypted state?
> Reasonably easy; you could use a pipe, for example, provided that both
> programs support it. Another way would be to use a ramdisk (is there a
> ramdisk filing system for Linux).
The potential problem I saw with the first is that I wasn't sure this
guaranteed it wouldn't pass through storage on disc. I understand one can
prevent a process from using swap space, but didn't know if that was
enough.
Regarding the ramdisc option, the only problem with that is the need to
have all the data in it at once, which wouldn't be so if one used a buffer
in memory as a cache for decrpyted data, refilling when there is demand
for data not currently in the cache.
> A third way, and this is a long term aim of stes, would be to allow stes
> to use the NFS protocol to pretend to be a network filing system.
I can see how that would work well, but don't know the protocol or how it
would likely be implemented, so have no idea how secure the decrpyted data
would be. I guess it could use a cache such as above?
> (Of course, none of these methods is secure if someone else has root on
> your PC).
The kind of security I was after is two fold. First, after the data has
been decrypted, used & discarded, there should be no possibility of
decrypted data being recovered from harddisc, either from deleted
temporary files or swap. Second, if possible, that the state of the system
at all times should be such that if the power is cut, all sensitive data
is lost (once the contents of memory have become irretrievable).
Are your aims likely to meet these requirements?
> >Can a program, that doesn't know it's handling sensitive data, be
> >wrapped up in such a way that it is protected from doing anything
> >undesirable with that data? A naive approach would be a mechanism to
> >only permit it access to files in memory, but that could require huge
> >amounts of memory.
> Modern PCs have 64-128M of memory, which is plenty for many applications.
For many, yes - but for some applications data of the order of GBs is
involved. Incidentally, any idea what speed will be like, very roughly?
[Snip]
> >(*) a minor question: can a zero length file be encrypted, merely to
> >ensure a key is present in the data for subsequent use?
> Yes.
Ah, good :)
--
_ _
Michael Rozdoba ICQ: 15835336 |_| |_ | |_| i'm trapped | | |
Ashamed to belong to a club called ACNE | | |_ |_ | in reality ... o o o
mroz at ukgateway dot net // ......... homepage coming soon .........
------------------------------
** 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
******************************
