Cryptography-Digest Digest #370, Volume #13 Wed, 20 Dec 00 16:13:00 EST
Contents:
Re: Steganography using text as carrier (Richard Heathfield)
Re: Steganography using text as carrier (Mike Tulley)
Re: Steganography using text as carrier (Richard Heathfield)
Re: Should I use Protocol 1.0 (RSA) or Protocol 2.0 (DSA)? ([EMAIL PROTECTED])
Re: Should I use Protocol 1.0 (RSA) or Protocol 2.0 (DSA)? (jtnews)
Re: Steganography using text as carrier ([EMAIL PROTECTED])
Symmetric "key exchange" protocol? (Ichinin)
Re: cipher algorithms once again... (Simon Johnson)
Tips in identifying a cipher (Jason Petrone)
Re: cipher algorithms once again... (John Savard)
Re: cipher algorithms once again... ("maciek")
Whitehouse e-mails ("CMan")
Re: SMS security over various networks? (Simon Johnson)
Blum Blum Shub ("Dobs")
Re: Unguessable sequence of unique integers? (Simon Johnson)
Re: Blum Blum Shub (Chris Rutter)
----------------------------------------------------------------------------
Date: Wed, 20 Dec 2000 11:59:03 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Steganography using text as carrier
Mok-Kong Shen wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> [snip]
> >
> > is there a way to hide already encrypted messages (ciphertext block)
> > within a *text* carrier,(not within the whitespace) and if so, what are
> > the size constraints of ciphertext to carrier text?
> >
> > as redundancy would not be particularly surprising in spam messages,
> > this might be a promising new avenue for effective steganography.
>
> Steganography is very much an art in my humble view. I
> don't think that there is any algorithm (automatic means)
> of doing the job you described, though there are methods
> of hiding bits in pixels etc. (A number of proceedings
> on information hiding have been published by Springer
> Verlag from which more pointers could be obtained.)
Just a thought:
Let C = E(P, K)
So we have an encrypted text, using J Random Encryption Algorithm, and
we must assume that our output is in binary format. We can look at this
data as a bunch of nybbles. There are sixteen distinct possible values
for a nybble, to which we could ascribe letters as follows:
IF you feel like it
Count the frequencies of the nybbles within the ciphertext
Assign each nybble value, in decreasing order of frequency, to the
following letters: s, c, a, p, b, r, d, i, m, e, t, f, h, g, l, w (based
on a cursory inspection of /usr/dict/words)
ELSE
Assign each nybble value to some random letter
ENDIF
(Note: the actual correspondences of nybbles to letters act as a
rudimentary key, but there's no real security in that fact as far as I
can see.)
For each nybble in the ciphertext
Generate a random English word beginning with the corresponding letter
Unassigned letters can be used for "filler" words to make the text more
convincing.
Just how effective this steganographic technique could be depends
largely on the quality of the text generation algorithm, especially
given the constraint that words must be chosen for their initial
letters.
Of course, like any steganographic technique published in sci.crypt, the
technique is somewhat weakened by the fact of its having been published
in sci.crypt.
Also, there's a huge amount of redundancy here - you only get four bits
of genuine information per English word - less if you use "filler"
words. For short messages, however, it could be of some limited
usefulness, even if only for a little elementary practice in
cryptanalysis. :-)
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: [EMAIL PROTECTED] (Mike Tulley)
Subject: Re: Steganography using text as carrier
Date: Wed, 20 Dec 2000 16:49:44 GMT
On 19 Dec 2000 18:56:46 -0600, Andre van Straaten
<[EMAIL PROTECTED]> wrote:
>
> The signs and the omens are everywhere
> But too few see them - too few even care
> (Lee Clayton - singer/songwriter, 1979)
I have a suggestion: you could hide the cyphertext in signatures which
claim to be music lyrics. There is no expectation that these will make
sense!
Mike
Mike Tulley ("net") = f("ofu")
(my real e-mail address) = f("nlutztAufmvtqmbofu/ofu")
------------------------------
Date: Wed, 20 Dec 2000 17:25:30 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Steganography using text as carrier
Mike Tulley wrote:
>
> On 19 Dec 2000 18:56:46 -0600, Andre van Straaten
> <[EMAIL PROTECTED]> wrote:
>
> >
> > The signs and the omens are everywhere
> > But too few see them - too few even care
> > (Lee Clayton - singer/songwriter, 1979)
>
> I have a suggestion: you could hide the cyphertext in signatures which
> claim to be music lyrics. There is no expectation that these will make
> sense!
<g>
Or indeed you could hide information in the music score itself. This was
done during WWII, apparently.
The agent in question was nearly caught when a German officer saw the
(hand-written) score and demanded to /hear/ the music. It sounded
/dreadful/. The agent, however, was quick-witted enough to pass it off
as "this modern rubbish", and got away with it.
(I'd love to offer you a reference for this little tale, but I can't - I
/think/ it was a little snippet in Readers' Digest, which gives you an
idea of how authoritative the account may or may not be.)
Having read about that, I devised a similar scheme (about 20 years ago!)
which avoided this weakness, by using redundancy - only unadorned
crotchets encoded information, so quavers, dotted crotchets, minims,
rests etc could be used with carefree abandon to make the music more
aesthetically convincing.
The encryption scheme itself was very weak, of course, being a simple
MSC (the pitch of the note corresponding to the letter of the alphabet -
so you need to use two staves at least), but that could easily be fixed
up.
Bandwidth? Forget it!
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Should I use Protocol 1.0 (RSA) or Protocol 2.0 (DSA)?
Crossposted-To: comp.security.ssh
Date: Wed, 20 Dec 2000 16:40:41 GMT
In sci.crypt jtnews <[EMAIL PROTECTED]> wrote:
> Thanks for the link! Guess I'll go with 2.0!
That may or may not be decided for you by the other endpoint. The
"real" ssh changed to a very restrictive license for 2.0, and many
implementations were forced to stick with 1.0 as a result.
That may or may not be an issue, but don't be surprised if your client
falls back to 1.0 on some connections.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
Date: Wed, 20 Dec 2000 12:53:30 -0500
From: jtnews <[EMAIL PROTECTED]>
Crossposted-To: comp.security.ssh
Subject: Re: Should I use Protocol 1.0 (RSA) or Protocol 2.0 (DSA)?
Oh, I'm only using ssh and sshd internally on my home network.
[EMAIL PROTECTED] wrote:
>
> In sci.crypt jtnews <[EMAIL PROTECTED]> wrote:
> > Thanks for the link! Guess I'll go with 2.0!
>
> That may or may not be decided for you by the other endpoint. The
> "real" ssh changed to a very restrictive license for 2.0, and many
> implementations were forced to stick with 1.0 as a result.
>
> That may or may not be an issue, but don't be surprised if your client
> falls back to 1.0 on some connections.
>
> --
> Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Steganography using text as carrier
Date: Wed, 20 Dec 2000 18:17:02 GMT
> There is a book:
> Peter Wayner, Disappearing Cryptography, AP Professional, 1996,
> which I bought at www.bookpool.com
>
> I've read only the first chapters about messaging via error-correcting
> codes, but the main part is about generating and altering ASCII text.
Thanks! This sounds exactly like what i have been looking for.
was thinking of something along the following lines:
assign a number (000 to 255) for each existing ascii character, as
well as a number for , <space>, <tab>, <linebreak>,<paragraph>.
assume a range of 000 to 300, (with many numbers not yet assigned, but
with room for future assignment)
compare any text (T) to any desired carrier text, (C) character to
character, and the difference between the the character in (T) and the
character in (C) can be represented by a number
[using positive integers only, ~ e.g. if the character <d> in T is
represented by 100, and the character <b> in C is represented by 98,
the difference would be represented by the number 298 {300-100+98} not
by the number 2]
the offset between any text T and any carrier C, will be able to be
expressed as a string of three digit integers, resulting in one very
large integer , which can be expressed as an MPI.
the relative sizes of T and C do not matter, as the difference
between empty space in one and a corresponding character in the other,
can still be expressed as a three digit integer.
so,
the algorithm would first convert T and C into strings of three digit
integers,(compare sizes of T and C, and add the three digit integers
representing empty space to make T and C of equal length), and then
generate an MPI representing the offset.
all that would remain to do is to 'hide' the string representing the
MPI somewhere in C,
? by some type of 'marking' the characters in C,
{this is the part i'm having trouble with, 8^) }
as the text T can already be an encrypted ciphertext block, there is no
need to encrypt the encoded MPI string.
any type of innocent e-mail or existing spam that one receives,
modifies with the mpi string, and forwards to someone else, could be
used,
[but agree with you, would prefer to use innocuous e-mail plaintext as
carrier text].
alternatively, if there is no way to effectively disguise the MPI
within the carrier text, this method may be used as a form of
cryptography [for text only] not dependent on keys and the underlying
mathematical problems that their security is based on.
all that would be necessary is the agreement (in advance) between Bob
and Alice on the initial carrier text,
e.g., a certain page of a specific text that both have access to.
then Bob can type a long text of (pseudo)random keyboard characters,
generate the MPI of the offset of this new text of gibberish characters
and the agreed upon carrier text, send the MPI to Alice, with the
understanding that the resultant gibberish text be used as the carrier
text for further communications, and then periodically change the
carrier texts in a similar manner.
hope that i have articulated this clearly,
thanks again,
vedaal
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Symmetric "key exchange" protocol?
Date: Tue, 12 Dec 2000 18:04:46 +0100
Hi.
Challenge: Try to spot any security in this protocol :o)
1) R = N bit Randomstring, negotiated over the network.
2) P = Private Key, a fixed key installed on both computers
3) S = Hash(P & R) /* Note: concatenated */
4) S is used as session key for client A and B.
Regards,
Glenn
Email address is for spammers, bounces regardless.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: cipher algorithms once again...
Date: Wed, 20 Dec 2000 19:09:59 GMT
In article <91ql81$7mk$[EMAIL PROTECTED]>,
"maciek" <[EMAIL PROTECTED]> wrote:
> Actually, could you tell me the names of currently used ciphers? I
need to
> do some research and I even don't have anything to start with. I know
that
> there are DES, 3DES, Rijndael (AES). Are there any others?
>
> Thank you very much for any answers.
>
> Maciek
>
>
The list is very long, but here are a few from different classes of
cipher:
Block Algorithms:
Blowfish
Twofish
Cast
IDEA
FEAL
RC5
RC6
Stream-Cipher:
RC4
Seal
Self-Shrinking Linear Feedback Shift Registers.
Fish
PKZip (woefully insecure, but its used in Winzip)
WAKE
Blum-Blum Shub
Hope that's enough to get you started,
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Jason Petrone <[EMAIL PROTECTED]>
Subject: Tips in identifying a cipher
Date: Wed, 20 Dec 2000 19:04:52 +0000
I am trying to learn about the encryption used in Microsoft's .lit format.
This encryption is intended to prevent tampering, and does not require the
user to provide a key. Any keys used are embedded in the .lit file or in the
creation/reader programs.
For any given plain-text, 3 significant file segments are created: An ASCII
GUID(unique id), a short binary section A, and a long binary section B.
Different output for all three segments is produced even when files are
created with identical input text. The lengths of A and B vary in regular
intervals(multiples of 16 or 32, I forget which).
Opening files with a modified GUID or short section A results in an
unqualified error message. When section B is modified, the file opens, but
no text is displayed.
I am guessing the key is based on the GUID, section A is a signature, and
section B is the encrypted text. Or perhaps section A is the key and the
signature is included with the text in section B.
What clues should I be looking for to identify the algorithm in use? I
understand that it could be quite difficult to actually decode the files, I
would be content just determining the cipher and key length used(if any). Is
this a hopeless venture?
I have more data as well(such as why I have ruled out XOR), but I would like
to keep this post short.
thanks
-jason
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: cipher algorithms once again...
Date: Wed, 20 Dec 2000 19:27:32 GMT
On Wed, 20 Dec 2000 17:06:44 +0100, "maciek" <[EMAIL PROTECTED]> wrote, in
part:
>Actually, could you tell me the names of currently used ciphers? I need to
>do some research and I even don't have anything to start with. I know that
>there are DES, 3DES, Rijndael (AES). Are there any others?
Visit my web site; several algorithms in current use, such as DES,
Rijndael, IDEA, Blowfish, and others, are fully described in detail
there, along with clear explanatory diagrams.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "maciek" <[EMAIL PROTECTED]>
Subject: Re: cipher algorithms once again...
Date: Wed, 20 Dec 2000 20:27:44 +0100
Thanks for answer.
So there are two groups which are pratically used these days: block and
stream ciphers, am I right?
If I had to name, let's say ten mostly used algorithms, what would be the
right order?
> Block Algorithms:
>
> Blowfish
> Twofish
> Cast
> IDEA
> FEAL
> RC5
> RC6
>
> Stream-Cipher:
>
> RC4
> Seal
> Self-Shrinking Linear Feedback Shift Registers.
> Fish
> PKZip (woefully insecure, but its used in Winzip)
> WAKE
> Blum-Blum Shub
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Whitehouse e-mails
Date: Wed, 20 Dec 2000 13:09:19 -0700
Clinton Whitehouse - Be Afraid, Be Very Afraid
Copyright Ó 2000 By John E. Kuslich - CRAK Software http://www.crak.com
The recent flapdoodle over Whitehouse e-mail is the tip of a massive
electronic iceberg. Our electronic Titanic is right on course for a disaster
of monumental proportions. Politicians and officeholders especially are at
risk. The problem is of sensitive information leakage through e-mail files.
For the rest of the article go to http://www.crak.com/clinton.htm
JK
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: SMS security over various networks?
Date: Wed, 20 Dec 2000 20:16:59 GMT
In article <[EMAIL PROTECTED]>,
Chris Gillespie <[EMAIL PROTECTED]> wrote:
> Chris Kantarjiev wrote:
>
> > I'm trying to put together a white paper on the relative merits of
text
> > messaging security via SMS over the various cell networks: CDMA,
GSM,
> > AT&T's TDMA.
> >
> > I've found a number of links about voice security, but they're
mostly
> > fluff, and they never really mention whether the same
> > algorithms/techniques apply to SMS when sent over the network.
> >
> > I can find references, for example, to A5 for GSM, and A5 having
been
> > broken, but no clear information about how A5 is or isn't used for
SMS
> > (as opposed to voice).
> >
>
> HA HA HA!! Sorry to skew off the point guys, but I've just
>
> been looking into GSM encryption for this question, and
>
> Applied Cryptography says it was my University that leaked
>
> the details of the A5 algorithm. I don't know if I shoud
>
> be proud or ashamed....
>
> Chris.
>
> --
> --
> Chris Gillespie
> Researcher
> Dept of Computing
> University of Bradford
>
> email: [EMAIL PROTECTED]
>
>
Proud, security through obsecurity should be destroyed at all cost.
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: Blum Blum Shub
Date: Wed, 20 Dec 2000 21:37:16 +0100
Hello,
I wonder if You can help me. I am looking for implemented in C Blum Blum
Shub random number generator. I know that there is one implemented in Visual
C in Crypto++. However I am looking for implementation in C not in Visual
C. Could You please inform me where can I find it or if You got it just
send it to me???????????
Best Regards
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Unguessable sequence of unique integers?
Date: Wed, 20 Dec 2000 20:37:58 GMT
In article <[EMAIL PROTECTED]>,
moc.qit@nahoj wrote:
> Hello.
>
> I am looking for an algorithm for a generator of a sequence
> of unique and unguessable 32-bit integers.
> The number of integers created by the sequence must be
> very large, i.e. in the 32-bit range and no two values
> in the sequence must overlap until a fairly large number
> (a minimum of 2^24 or so) of values have been found.
>
> I suppose I could do this by using a simple counter
> and encrypting the result with a symmetric algorithm.
> Is there a good freely available implementation of a simple
> algorithm?
>
> .. but more interestingly, is there any better way of creating
> the sequence?
>
> Thanks in advance for any replies.
> / Johan
>
> (my reply-email is backwards)
>
Use an LFSR of order 37, in self-shrinking mode. This will produce 2^32
32-bit words for any input key before any collisions occur.
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Chris Rutter <[EMAIL PROTECTED]>
Subject: Re: Blum Blum Shub
Date: 20 Dec 2000 20:50:41 GMT
Dobs <[EMAIL PROTECTED]> wrote:
> C. Could You please inform me where can I find it or if You got it just
> send it to me???????????
(willow) ~/src/catacomb-2.0.0pre6 less bbs.h
/* -*-c-*-
*
* $Id: bbs.h,v 1.5 2000/07/01 11:20:24 mdw Exp $
*
* The Blum-Blum-Shub random bit generator
*
* (c) 1999 Straylight/Edgeware
*/
There's one available as part of Catacomb. You can download the source
from <http://www.excessus.demon.co.uk/misc-hacks/#catacomb>.
c.
------------------------------
** 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
******************************
