Cryptography-Digest Digest #108, Volume #14 Sun, 8 Apr 01 20:13:00 EDT
Contents:
Re: How good is steganography in the real world? ("Frank Young")
Re: JPEG also problematic (Mok-Kong Shen)
Re: anyone have digital certificates sample code (Anne & Lynn Wheeler)
Steganography with natural texts (Mok-Kong Shen)
Re: Delta patching of encrypted data ("Anon")
co-author wanted for a paper (SAC conference...) ("Tom St Denis")
Re: anyone have digital certificates sample code (Paul Rubin)
Re: Dynamic Substitution Question (newbie)
Re: Delta patching of encrypted data (David Wagner)
Re: Delta patching of encrypted data (Mok-Kong Shen)
Re: New stream cipher (=?ISO-8859-1?Q?Jacques_Th=E9riault?=)
Re: How good is steganography in the real world? (Charles Lyttle)
Re: Steganography with natural texts (Joe H Acker)
Re: Would dictionary-based data compression violate DynSub? (David Formosa (aka ?
the Platypus))
----------------------------------------------------------------------------
From: "Frank Young" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: How good is steganography in the real world?
Date: Sun, 8 Apr 2001 13:26:40 -0700
> Bruce Schneier had an excellent talk about this at DEF CON one year; I
don't
> know if he ever wrote it down (perhaps in one of the issues of the
> CRYPTO-GRAM newsletter?). He made the point that if two people suddenly
start
> sending GIFs to each other, whereas previously they had not done so, this
may
> attract suspicion. especially if the GIFs are pretty silly looking things
> like pictures of flowers. Enough suspicion and people come to your house
with
> rubber hoses...
>
One has to wonder why the "Technology Advisor" who started this whole thread
thinks that no one from Iraq will read it... including the employees of the
company he works for who are stationed in Iraq.
Just a suggestion Gil, in case this is not a troll and you really don't have
a clue what you have just done wrong....
When everyone in Iraq suddenly wants to come home for vacation you should
think about taking a long vacation yourself.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: JPEG also problematic
Date: Sun, 08 Apr 2001 22:38:06 +0200
Frank Gerlach wrote:
>
> Mok-Kong Shen wrote:
>
> > I have no knowledge but wonder voice in normal telephone
> > communications couldn't carry stego bits rather easily,
> > since all people speak differently (accents, male/female,
> > age, etc.) and at different times (health, emotions etc.)
> > so that differences due to stego modifications could be
> > very hard to detect.
>
> So you would want to distort the phase and amplitude (let's use those crude
> frequency domain terms) in order to encode the hidden information ?
> I agree this is difficult to detect for an automated system, but then whatbout
> the Mk1 acoustic bio-neural system (aka. "ear") ?
> There are obviously two major approaches:
> 1. distorting the bogus signal (voice, music, images, video)
> 2. distorting the noise of the sampling process
>
> Approach 1 is very difficult to assess, as a difficult-to-understand opponent
> (the trainable and genetically varying human brain) is involved.
> Approach 2 "only" makes assumptions about mathematical methods.
I do think that approach 1 is practically viable in voice,
since in general situations the opponent has to face the
fact that there are many candidate speakers and these are
unknown to him. (The speakers may also be foreigners of the
language employed.) Of course, the ratio of embedded bits
to the total volume of communication has to be kept
sufficiently low.
M. K. Shen
------------------------------
Subject: Re: anyone have digital certificates sample code
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sun, 08 Apr 2001 20:51:06 GMT
"normang" <[EMAIL PROTECTED]> writes:
> Does anyone know of sample working code to create digital certs.
>
> We are trying to write a system for user authentication using our own
> digital certificates for a internal user base (and so not have to shell out
> to Verisign every time!). We intend to use ebcrypt as the basis for the
> encryption requirements and transfer the packages using tcp/ip.
>
> Thanks in advance.
>
> Basically we want to issue x509 certs of out own and user a Kerberos type
> system
even simpler would be to take radius and implement digital signature
authentication (i.e. public key recorded in an internal radius
database) for user authentication. then the radius protocol allows for
a wide-range of applications with access to the real-time database.
aka the registration authority part of registering public key w/o
having to do the certification authority piece (i.e. since they are
internal they presumably don't need 3rd party certification)
... and/or w/o having to implement offline trust propogation (which is
the fundamental purpose of issuing a certificate .... i.e. propogating
the trust that has been certified into offline environments).
random refs:
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
http://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 vs XML
(used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm4.htm#10 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital
Signatures
http://www.garlic.com/~lynn/aadsmail.htm#complex AADS/CADS complexity issue
http://www.garlic.com/~lynn/aepay2.htm#cadis disaster recovery cross-posting
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Steganography with natural texts
Date: Sun, 08 Apr 2001 22:47:30 +0200
Most modern stego schemes are based on embedding bits in
pictures. A current thread in the group is discussing that.
I suppose that a competitive way is to embed bits in natural
language texts. Previously I proposed a method exploiting
the format freedom of html files. In the following I like
to present some preliminary thoughts of an alternative,
though implementationally more expensive, scheme that
can easily utilize all natural language covertexts, e.g.
e-mails.
Let's partition the set of words that are relevant to the
normal messages of the communication partners into
disjoint subsets, i.e. groups of synonyms, including such
possible groupings as personal names, names of merchandizes,
family relations, etc. that could be reasonalbly interchanged
in given contexts without causing the sentences modified to
become unnatural and thus suspicious to the opponent. Each
such subset can be arbitrarily divided, dependent on a secret
key, into two parts, with one part representing the bit 0 and
the other part the bit 1. Now, given a piece of normal
correspondence, a software could scan for the words that are
in these subsets. If such a word happens to correspond
positionally to a bit of the secret message to be embedded,
then no action is taken. Otherwise, the word is highlighted
and the user can then choose a substitute from a list of
words that are in the other half of the subset to which that
original word belongs.
Of course, the covertext must be long enough to be able to
embed all the bits of the secret message. A technical point
is how to signal the end of the embedded bit sequence,
since there may be further words in the covertext that also
belong to the agreed-upon subsets. One possibility is to
reserve one or two words in each subset for that purpose.
I should very much appreciate comments and critiques.
M. K. Shen
============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Anon" <[EMAIL PROTECTED]>
Subject: Re: Delta patching of encrypted data
Date: Sun, 8 Apr 2001 22:25:39 -0000
Regrettably the diff program is third party.... I think I'll have to put up
with weaknesses. Bearing in mind the usual attacks aren't cryptological in
nature, that shouldn't be *to* much of a problem!
The problem with David Wagner's solution is that if the insert isn't a
mulitple of "N", each subsequent block isn't any of the old blocks. Imagine
a sequence ABCDEFGHIJKL encrypted using a block size of 2 characters. (hence
AB CD EF GH IJ KL) Insert one character in the middle to get ABZCDEFGHIJKL,
the blocks become AB CZ DE FG HI JK L - and only the first one was in the
original file. That's why I;m looking to go away from our current block
mode scheme.
""Bryan Olson"" <"nospam"@"nonsuch.org"> wrote in message
news:kCyz6.7$4G.94@interramp...
> those who know me have no need of my name wrote:
> >>Anon wrote:
> >>>We wish to take a file and encrypt it. At a later date we wish to take
a
> >>>new version of the file and encrypt that. We want to minimise the data
sent
> >>>to enable updates to the new version.
>
> >if you'd consider this method, you might want to encrypt the delta file
> >and deploy a patch program that can accept encrypted data and delta
> >inputs and output the updated data (already encrypted).
>
> I agree; that's the obvious solution and the more complex
> ones look worse.
>
> Compute the diff on the plaintexts, encrypt and send the
> diff. Receive the diff in ciphertext, decrypt and apply to
> the old file plaintext to get the new version plaintext.
>
>
> --Bryan
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: co-author wanted for a paper (SAC conference...)
Date: Sun, 08 Apr 2001 21:31:37 GMT
I am seeking a co-author (one with math+crypto knowledge) for my paper I
want to present at (or at least submit for) SAC. It's about a very compact
somewhat fast block cipher. It uses decorrelation theory as it's primary
source of security. On my i8032 it achieves a data rate of 9.1kbits/sec and
only requires 302 bytes (for the encrypt, decrypt and keysetup routines).
It only takes 161bytes of rom if the key is already setup and it only
performs one of decryption or encryption...
If you are intersted please email me, I will send you the current draft of
the paper... The deadline is May 7th so if you want to help you have todo so
quickly.
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: anyone have digital certificates sample code
Date: 08 Apr 2001 14:46:15 -0700
"normang" <[EMAIL PROTECTED]> writes:
> Does anyone know of sample working code to create digital certs.
www.openssl.org
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: Dynamic Substitution Question
Date: Sun, 08 Apr 2001 12:23:53 -0300
Is your idea working in this way (as explained by John Savard)?
Plaintext: 4 3 1 9 0 2 4 7
Keystream: 1 7 0 9 8 1 6
Table: 0|5 5 5>7 7>6 6 6
1|2>7 7>5 5 5>9 9
2|9 9 9 9 9 9>5 5
3|0 0>4 4 4 4 4 4
4|7>2 2 2 2 2 2>3
5|1 1 1 1 1 1 1 1
6|3 3 3 3 3 3 3>2
7|4 4>0 0 0 0 0 0
8|6 6 6 6 6>7 7 7
9|8 8 8 8>8 8 8 8
Ciphertext: 7 0 7 8 7 9 2 0
If it is the case, then this process contain big hole.
Let me know, because in your "paper", you are talking about shuffling
the table after every substitution.
Terry Ritter wrote:
>
> On Sat, 07 Apr 2001 19:42:58 -0300, in
> <[EMAIL PROTECTED]>, in sci.crypt newbie
> <[EMAIL PROTECTED]> wrote:
>
> >Ritter himself agree that Dynamic Substitution does not add randomness
> >comparing to OTP. I think that DS not only add nothing to randomness of
> >the keystream but it add more determinism to the keystream.
> >I can prouve it without statistical analysis.
> >Just by mathematical demonstration.
> >I'm working on it.
>
> "Ritter himself" sees Dynamic Substitution as a reversible nonlinear
> and keyable cryptographic combiner. One use is to replace the
> reversible but LINEAR and non-keyable additive combiner (e.g., XOR)
> used in stream ciphers and "One-Time-Pad" (OTP). That combiner is
> typically used to mix plaintext data and a "keying sequence" or
> "confusion sequence" produced by some sort of Random Number Generator
> (RNG). That is how plaintext is carried on the apparently-random
> ciphertext stream.
>
> The reason one might want to use a better combiner is that the classic
> attack on additive stream ciphers is "known-plaintext": if the
> opponent gets some plaintext which can be associated with the
> ciphertext, that will expose the raw "confusion sequence" which can
> then attacked on its own. We do assume that the opponent has known
> plaintext. We also assume the opponent knows the electronic or
> logical details of the RNG that produces the confusion sequence, so
> that, knowing the raw output, there is decent chance of opening that
> up, and then predicting the sequence forward and backward. There is a
> long history of doing exactly this sort of thing.
>
> In contrast, when we have a nonlinear and keyable combiner, simply
> having known-plaintext does not immediately reveal the confusion
> sequence. That complicates attacks and hopefully stops the opponent
> well before encountering a generator which might be analyzed and
> broken. But in the same way that there is no proven-secure generator,
> Dynamic Substitution is no panacea; it is just a tool to improve
> stream cipher security. On the other hand, we already know that XOR
> has no strength at all against known-plaintext.
>
> I recommend that *some* sort of nonlinear (non-additive) combiner even
> for the OTP. That would of course not be necessary if we could simply
> *assume* that the OTP keying sequence was in fact absolutely
> unpredictable. But that is something which at this point cannot be
> proven and also cannot be tested. It consequently makes sense to
> assume that predictability is present, and then take steps to hide
> that. For anyone interested in real security, using a keyed nonlinear
> combiner (e.g., a Latin square, or, yes, Dynamic Substitution) makes a
> lot of sense, even in an OTP design.
>
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Delta patching of encrypted data
Date: 8 Apr 2001 22:33:30 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Anon wrote:
>The problem with David Wagner's solution is that if the insert isn't a
>mulitple of "N", each subsequent block isn't any of the old blocks.
You didn't read my suggestion carefully enough. I suggested that
each chunk contain *at most* N blocks, not exactly N blocks. With
this property, you can easily ensure that changes to one chunk don't
avalanche to other chunks.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Delta patching of encrypted data
Date: Mon, 09 Apr 2001 00:37:50 +0200
Anon wrote:
>
> We wish to take a file and encrypt it. At a later date we wish to take a
> new version of the file and encrypt that. We want to minimise the data sent
> to enable updates to the new version.
>
> If the file is not encrypted, we can use a delta patcher program, which
> picks up insertions, deletions, and alterations to the file and works out a
> script. The script and the original file can then be used to generate a
> copy of the new file.
>
> With normal encryption this doesn't work. If we use a stream cipher, all
> data from the first change onwards is altered. If we use a block cipher
> with no feedback any insertion or deletion which is not a multiple of the
> block changes all the file from there onwards.
>
> I'm thinking in terms of a self-synchronising cipher based on the previous
> plaintext, rather than the previous ciphertext. Obviously this will be
> weaker - if for example there is a large sequence of repeated characters the
> ciphertext will settle down to a consistent value - however:
>
> Is there a standard solution to this problem?
> If not, how weak is the solution I describe?
I might be wrong. But isn't it that a version managing
software takes care of the updates such that with the
original and a series of deltas one gets the current
version of a program source or other texts? Now, if you
consider the original and the deltas each as a separate
piece and encrypt them and send these to the recipient,
he can decrpyt these and use the managing software
to obtain the current version just as you can do, isn't
it? So I certainly haven't yet understood your problem.
M. K. Shen
------------------------------
Subject: Re: New stream cipher
From: [EMAIL PROTECTED] (=?ISO-8859-1?Q?Jacques_Th=E9riault?=)
Date: Sun, 08 Apr 2001 23:29:40 GMT
MarinaP <[EMAIL PROTECTED]> wrote:
This might be premature since all the tests are not done yet, but I've
got something on my site www.angelfire.com/mt/nightbird/Mcter.html that
might suite your taste for analysis.
Jacques
> Hi, all!
> I would like to analyze a new stream cipher.
> Where can I find it?
> Where can I find RC4-like ciphers?
> What stream ciphers are used in practice? -RC4, A5, PKZIP ( It is clear.)
> Thank you.
------------------------------
From: Charles Lyttle <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: How good is steganography in the real world?
Date: Sun, 08 Apr 2001 23:40:41 GMT
I did read your article, but perhaps I misunderstood. I think it very
unlikely that there is a backdoor into either RC4 or DES. Cracking DES
would be of such economic value and so many eyes have looked at it, that
I am sure that any backdoor would have been found by now. As an example
the Russian GOST was cracked fairly quickly even though it was a minor
variant of DES. GOST turns out to have weak keys and strong keys. The
KGB was giving out weak keys to people it wanted to watch.
As for OTPs from WW II being still secure, that isn't the case. Military
OTPs that I have used have all been limited to information that would be
invalidated after about 1 week. This is because it is assumed that the
pad itself is comprimised after that time. i.e. someone lost a copy or
the enemy captured a copy. Much OTP from WW II is not secure because
copies of the pads are still around. Some might be secure because all
copies of the pads have been lost, but this won't be the majority.
Any one in this group got any WW II OTPs in a trunk in the attic? I
think my uncle has some he captured from a German officer in North
Africa. If still there, the date, time, and place of capture will be
available. People doing historcal research can contact me, and if you
check out, I can try to dig them up. Nothing guaranteed though.
Frank Gerlach wrote:
>
> Charles Lyttle wrote:
>
> > Frank Gerlach wrote:
> > >
> > > >
> > > >
> > > > Enigma, Navaho and other WWII encryption techniques would not be
> > > > secure today.
> > >
> > > That's an over-generalized statement. OTP properly applied in WW2 will
> > > be secure forever, and eben some WW2 hand-codes might still be secure.
> > > Also, the doctrine "security by obscurity is bad" might not be so true.
> > > Look at DES or RC4: All spooks around the world had now quite some time
> > > to look at those very interesting targets. One could argue that this
> > > long period of cryptanalysis might have produced new methods, which are
> > > specifically useful against those ciphers. I am pretty sure a future
> > > generation will look at (3)DES and RC4 in the same way we look at Enigma
> > > today :-)
> > Neither DES nor RC4 rely on security by obscurity. Both are published
> > and can be analyzed.
>
> Did you read my posting ? I said that exactly this might make them weak.
> (Bruce Schneier said the same in "Applied Crypto"regarding DES) Have you
> every asked yourself why the NSA uses PCMCIA cards ("Fortezza") instead of
> software ? Maybe because they want to deny an opponent the opportunity to
> analyze the cipher. I bet they have a full DoD stock of cards with a
> different cipher available for deployment in a time of crisis. In addition to
> an OTP system for highest-level communications, of course.
>
> >
> > Using code-talkers (such as the Navaho) has another problem. The
> > English->Navaho#1->Navaho#2->English translation sequence resulted in
> > corruption of information. Navajo and English are not one-to-one. Some
> > English words/concepts do not translate well into Navajo, and some
> > Navajo words/concepts do not translate well into English. The same is
> > true of any two languages. Also you never know when the servants have
> > learned your language.
> >
> > --
> > Russ Lyttle
> > "World Domination through Penguin Power"
> > The Universal Automotive Testset Project at
> > <http://home.earthlink.net/~lyttlec>
--
Russ Lyttle
"World Domination through Penguin Power"
The Universal Automotive Testset Project at
<http://home.earthlink.net/~lyttlec>
------------------------------
From: [EMAIL PROTECTED] (Joe H Acker)
Subject: Re: Steganography with natural texts
Date: Mon, 9 Apr 2001 01:36:25 +0200
There are two problems with your proposal:
(1) The steganographic channel you've chosen (=lexical choice by
speakers) does not have enough redundancy for practical purposes.
(2) You seem to assume that any choice for a certain expression is
equally possible for any speaker
(2) is the main problem in current steganography: I believe that the
encoding you need to find is not a random choice between the possible
alternatives, but has to be based on the actual statistical distribution
of occurances of such choices, i.e. it has to be based on the relative
frequencies the alternatives usually occur with.
Remember that it's almost trivial to distinquish a certain speaker from
others just by analysing the words he has chosen, provided you have
enough sample data.
A good steganographic algorithm must do the following: It has to map a
message of the "cover" channel into a redundant variation of the message
by using a key such that each variation of the message could be a secret
message with equal probability. But since variations of a message in
most channels are not equally probable, the actual encoding of a secret
message regarding some specific channel must take the frequencies of the
possible variations into account.
In case of synonyms, you would need to find an encoding that takes the
frequencies of variations in lexical choice of an actual speaker into
account to find the optimal steganographic encoding. Since speakers vary
a lot in lexical choice, you cannot find a good common denominator that
matches all speakers. So your encoding can be attacked provided there is
enough "steganofied" sample material. I cannot say how much data you'd
need for such an attack, but I doubt it would be very much.
Regards,
Erich
------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: Would dictionary-based data compression violate DynSub?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 08 Apr 2001 23:56:04 GMT
On Sat, 07 Apr 2001 07:29:55 GMT, Terry Ritter <[EMAIL PROTECTED]> wrote:
>
> On Sat, 07 Apr 2001 06:24:53 GMT, in
><[EMAIL PROTECTED]>, in sci.crypt
> [EMAIL PROTECTED] (David Formosa (aka ? the Platypus)) wrote:
[...]
>>How is the application diffrent from Algorithm M?
>
> Perhaps you should first try to replace the XOR in a stream cipher or
> OTP with Algorithm M, and see what the problems might be.
So basically the Patant covers using a dynamic substition table when
combining a keystream with a datastream? And not when combining two
keystreems (in Algorithm M) or used to generate a keystreem (in the
case of RC4).
> And of course since there are no distinct sequences of data and
> confusion in Algorithm M, there is also no thought about how the
> process might be undone or the data extracted on the other end.
Ok that helps.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
------------------------------
** 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
******************************
