Cryptography-Digest Digest #243, Volume #11 Fri, 3 Mar 00 06:13:00 EST
Contents:
Re: Best language for encryption?? ("Douglas A. Gwyn")
Re: Best language for encryption?? ("Douglas A. Gwyn")
Re: Passphrase Quality ? (jungle)
Re: Best language for encryption?? ("Douglas A. Gwyn")
Re: Best language for encryption?? ("Douglas A. Gwyn")
Re: On jamming interception networks ("Douglas A. Gwyn")
Re: On jamming interception networks ("Douglas A. Gwyn")
Re: brute force attack on a 128 bit SSL key? ("Douglas A. Gwyn")
Re: Can someone break this cipher? ("Douglas A. Gwyn")
Re: very tiny algorithm - any better than XOR? (Carl Byington)
Re: Far out crypto claims ("Douglas A. Gwyn")
Re: Crypto.Com, Inc. ("Douglas A. Gwyn")
Re: very tiny algorithm - any better than XOR? (Paul Rubin)
Re: How to annoy the NSA & break almost any code ("Wesley H. Horton")
Re: Status of alleged *THIRD* key in MS Crypto API ? (Anthony L. Celeste)
Re: Can someone break this cipher? ("Wesley H. Horton")
Re: Crypto.Com, Inc. (Mok-Kong Shen)
Re: On jamming interception networks (Mok-Kong Shen)
Re: Solitiare Algorithm/Math Question? ("Wesley H. Horton")
Question about sort of signing ([EMAIL PROTECTED])
Re: Question about sort of signing ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Fri, 03 Mar 2000 06:31:58 GMT
Paul Schlyter wrote:
> C has only gone through one revision so far: in 1979 the first ANSI C
> standard was released.
1989. There was one amendment and two technical corrigenda, each of
which constituted a revision to the standard. In 1999 there was an
entire new release of the C standard. (It's actually an ISO standard
since 1990. ANSI adopts the ISO version.)
> Before that there was the older "K&R C", which wasn't a formal
> standard, but still fairly uniform across implementations, ...
Not so uniform. If it had been, there wouldn't have been so much
pressure to develop an official standard. (Not even Ritchie's own
C compiler fully conformed to the spec in K&R 1st Ed, and the most
popular porting platform at the time was PCC, which differed in some
ways from the Ritchie C compiler.) Absence of consensus was
especially felt in the area of library functions and system headers,
since not everything from the UNIX environment made sense in other
environments. Eventually we partitioned the libraries between
P1003 (POSIX, IEEE 1003.1) and X3J11 (ANSI C), and most non-UNIX
libraries such as Whitesmiths' were not adopted for the standard.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Fri, 03 Mar 2000 06:38:15 GMT
wtshaw wrote:
> In article <89l42r$9uc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul
> Schlyter) wrote:
> > If you want to go farther than that in C, use setjump/longjump
> > instead. ...
> > And then you also have signal().....
> No mention of these is in the literature I have on C/C++, ...
Paul misspelled setjmp & longjmp, but all three functions are
required by the C standard. It sounds to me like you're using
inferior "literature"; no wonder you don't seem to understand C.
> my point...that there is too little standardization in how the
> languages are fully used, as opposed to a set of commands that
> are easily learned, at least by many who I have taught.
I sure as heck hope you're not trying to "teach" C as you see it.
C is *quite* well standardized, and how to use Standard C to
program portably has also been quite fully developed.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Fri, 03 Mar 2000 06:40:37 GMT
Johnny Bravo wrote:
>
> Why do you think that
> .&Xq6:~mG_[Q>A)i3w'K is a better alternative for 128 bits?
yes, it's a better alternative for 128 bits, but I can't tell you why ...
there is one huge difference, this one I can tell you ...
you know your pass text all the time [ you did your pass text memorized very
well ], therefore several methods that are child play simple to use & execute
exist to get this pass text from you
to get your "simple two sentence mnemonic", irrespectively of your resistance
any time the AGENCY WOULD LIKE TO DO IT ...
when agency will like to get your "simple two sentence mnemonic", you will spit
it out on every request, like a baby spit a dummy
> Just because you can't remember a simple two sentence mnemonic, don't
> expect everyone else to be as limited.
LOL,
when you don't know how to make 16 char to safely enter as pass text don't
expect everyone else to be as limited ...
don't be constrain by conventional knowledge & wisdom
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Fri, 03 Mar 2000 06:43:06 GMT
"Trevor Jackson, III" wrote:
> I was referring to the construct ON <predicate> GOTO that many
> flavors of BASIC end up adding. It's far more powerful (a
> nebulous concept) than the typical IF <predicate> GOTO
You mean, exception handling. Exception handling isn't actually
"more powerful", but it is often much more convenient than having
to continually test for the condition(s). Lots of HLLs, including
Standard C++ and Java, support exception handling reasonably well.
Standard C doesn't have direct support for exception handling in
that style, although it does provide primitives that can be used
to build one's own similar facility. I wouldn't be surprised if
C++ exception handling facilities appeared in the next release of
the C standard.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Fri, 03 Mar 2000 06:46:39 GMT
wtshaw wrote:
> goto's are great for unconditional branching when you need them, like
> professional expediters in some companies that get around all the
> paperwork any which way they can.
Which is why you find that you are out of stock on an item when it
is critically needed.
Lack of discipline is not something to be proud of in an engineering
profession.
> You just solved a problem I have been having in C, make it run
> through a set of dummy values to get all the labels identifed...
> what a crock, ...
It certainly is a crock, but it's your fault for having a crappy
program design. Instead of trying to write BASIC in C, you should
learn to use C on its own merits. (Same for *any* language.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Fri, 03 Mar 2000 06:51:12 GMT
Mok-Kong Shen wrote:
> ... Evidently that is beyond the capability of 'logic'. One should
> also remember that there is not even a 'unique' logic. I happen to
> be in possession of a copy of a master thesis of somebody entitled
> 'Nonclassical Logics' with 387 pages!
That argument isn't even worthy of a sophomore.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Fri, 03 Mar 2000 07:03:29 GMT
Mok-Kong Shen wrote:
> Douglas A. Gwyn wrote:
> > No, it was a simple statement of fact.
> > When you repeat what you understand that I mean and it
> > doesn't at all match what I meant, then you don't show
> > signs of understanding my meaning at all.
> > And the sarcastic tone you used convinced me that you
> > weren't interested in understanding what I was saying.
> > So it *is* a good idea to terminate the thread,
> > because a discussion requires listeners as well as talkers.
> Ah, 'one shows signs of understanding your meaning' if and only
> if one 'agrees' with you, isn't that what you are saying above?
No, again you pretend to repeat what I said but it doesn't match
what I said. If you cannot summarize it accurately you have not
understood it.
> I would say that this is the viewpoint of a very 'naive' citizen
> who believes that all officials in the government are 'gentlemen'.
Well, you would be wrong yet again.
> ... [long speech omitted] ...
I've been explaining how the system *does* work, on the basis of
first-hand knowledge of its workings, primarily to counter false
accusations and to alleviate somewhat the public pressure to "do
something" about an incorrectly perceived situation, which would
not serve the public interest. Feel free to fantasize, but
realize that that is what you are doing.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: brute force attack on a 128 bit SSL key?
Date: Fri, 03 Mar 2000 07:07:11 GMT
Paul Koning wrote:
> Would you care to explain that?
Sure, but it would be repetitious: The whole approach is wrong;
it's a misapplication of thermodynamics.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Can someone break this cipher?
Date: Fri, 03 Mar 2000 07:12:42 GMT
Mary - Jayne wrote:
> >``The original plaintext was encrypted using traditional cryptological
> > methods. These include polyalphabetic encryption, randomised
> > cipher alphabets, and transformation; the whole process requiring two
> > keys to complete (or reverse).''
> >It *says* ``with method clues added 01-03-2000'' - but of them there's no
> >sign - did they really get uploaded?
> As you reproduced them in the previous paragraph, I would suggest you have
> answered your own question. Now just how specific did you want me to be?
If you seriously believe that that constituted a description of the
encryption algorithm, then you don't know much about algorithms.
An algorithm has to be a *recipe* that can be followed step by step,
with sufficient specification that there is no question about what
to do at any stage. The source code isn't necessary, but the
logical procedure is.
------------------------------
From: [EMAIL PROTECTED] (Carl Byington)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 3 Mar 2000 07:20:36 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Carl Byington wrote:
>> Consider an 8 bit processor that does not have enough code space memory
>> to run TEA. This processor only needs the decrypt side - it never
encrypts
>> any output. We have about 50 bytes of code space, which should be enough
>> for something like the algorithm below. [...]
>
>How much data space do you have? I would seriously recommend against
trying
>to create a new algorithm, but it may be possible to use a smaller variant
>of an already analysed algorithm.
The processor has 512 bytes of ram, but there are a lot of other demands
on that. We can have 20 to 30 bytes of ram for the encryption, 64 bytes
is not possible.
I fully agree with you about trying to create a new algorithm - this is a
desparate move to avoid something like a trivial xor. If we are reduced to
that we might as well not do any encryption.
>For example, RC4 can certainly be implemented in 50 bytes of code space
>(probably much less), so the only potential problem is its RAM
requirement.
>The standard, 8-bit version of RC4 requires 256 bytes, but I think it is
>probably safe to go down to about 6-bit RC4, which has a memory
requirement
>of 64 elements each of 6 bits (in that case it's probably best to store
each
>table element as a byte, and iterate the algorithm 4 times to encrypt 3
bytes).
>
>Here is psuedo-code for one iteration of n-bit RC4 encryption/decryption
>["^" means "to the power", not XOR]:
>
> i = (i + 1) mod 2^n
> t = S[i]
> j = (j + t) mod 2^n
> S[i] = u = S[j]
> S[j] = t
> t = (t + u) mod 2^n
> next n bits of keystream = S[t]
>
>and for key scheduling:
>
> let K[0..len-1] be the key.
> for i = 0 to (2^n)-1 {
> S[i] = i
> }
> for i = 0 to (2^n)-1 {
> t = S[i]
> j = (j + t + K[i mod len]) mod 2^n
> S[i] = S[j]
> S[j] = t
> }
>
>Note that, as for any stream cipher, you should not use the same key for
>more than one message, without adding a random salt.
Thanks for the pointer to RC4. However, the system design at this time
implies that we will use the same key for all the content owned by the
same entity (person, family, whatever). It will not be unusual for one
key to protect a few megabytes of content. I presume that we need some
secure mechanism of passing the random salt to the decryptor.
We don't have 64 bytes of ram. From your comments above I take it you
would not use 5-bit RC4?
- --
PGP key available from the key servers.
Key fingerprint 95 F4 D3 94 66 BA 92 4E 06 1E 95 F8 74 A8 2F A0
=====BEGIN PGP SIGNATURE=====
Version: 4.5
iQCUAgUBOL9nuNZjPoeWO7BhAQFFbAP3TJTjHehItglmXYAJ5MDswJYtdxJ7l209
NHxIw2y/K+Ep5wj8rJaPDlL0VM6l6AU1SqCiXvqvYcvoXtiHTyqKzIG8eOzTmhCB
Bmxsugxs0hrNkFzLe3sDjo9aWFYMQ4gZLDn1fdtGciB7nLAQpNTXvFvqSTmwD4cT
ul1nnhhSbA==
=qnNp
=====END PGP SIGNATURE=====
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Far out crypto claims
Date: Fri, 03 Mar 2000 07:26:45 GMT
[EMAIL PROTECTED] wrote:
> If I were a fanatic believer in ETs and their
> UFOs then I might have to accuse you of being
> affiliated with the Government and of trying
> to lead us astray. I would also say it is
> suspicious that you seem to know so much
> about this topic and cryptography as well and
> that you have the time and inclination for such
> a lengthy and detailed reply.
My contributions in this newsgroup are not in any official capacity.
You have to judge my veracity and reliability for yourself; there
is ample evidence available for your inspection.
My intent is to be helpful and informative, in support of my hope
that eventually everyone will be able to communicate in perfect
privacy. That requires better public understanding of cryptology.
I believe that that goal is consistent with legitimate national
interests, although some people in the business have taken a
short-sighted view of the matter and try to hold onto their turf.
If my wanting to contribute to building a better world seems
suspicious to you, that's not a reflection on *me*.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Crypto.Com, Inc.
Date: Fri, 03 Mar 2000 07:29:03 GMT
Mok-Kong Shen wrote:
> Douglas A. Gwyn wrote:
> > Mok-Kong Shen wrote:
> > > Another possibility: Telepathy! Believe it or not, it was only
> > > a few days ago that pre-cognition of animals and such stuffs
> > > were earnestly discussed in a French radio broadcast.
> > They were discussed today in Moe's Bar. So what?
> You probably meant that there are plenty of rather 'low class'
> stations which broadcast all kinds of stuffs. The one I was
> referring to is however not a minor one, it's Europe I.
Ooo, I'm *so* impressed! I bet they're almost as reliable as CBS!
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 3 Mar 2000 07:58:22 GMT
Carl Byington <[EMAIL PROTECTED]> wrote:
>The processor has 512 bytes of ram, but there are a lot of other demands
>on that. We can have 20 to 30 bytes of ram for the encryption, 64 bytes
>is not possible.
Oops, I didn't see this earlier. So much for my 8-bit rc4 suggestion.
Let me ask you something--is it ok for the encryption alg to use
tables that are in the eeprom and not count it as program space?
Can I ask what the application is? Maybe you could use some of the
cpu program space to code a small interpreter, and run "programs" from
the eeprom, migrating other parts of your application to eeprom except
for the speed critical parts.
Ignoring security issues, trying to do rc4 with 5 or 6 bits will
likely blow your 50 byte code limit because of the extra code needed
to shift the bits around to emit the output stream as 8-bit bytes.
How about a simple additive RNG? That should run faster and take less
code than a bit-twiddling LFSR. Cryptanalysis methods for it are well
known, but unlike xor, you at least have to know what you're doing to
break it. Since, as you say, attackers can get the plaintext by probing
the hardware, high cryptographic security might worth much trouble.
------------------------------
From: "Wesley H. Horton" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: How to annoy the NSA & break almost any code
Date: Fri, 03 Mar 2000 03:37:08 -0600
Better yet,
if you REALLY want to annoy them, post a message here that you have
discovered an absolutely unbreakable cipher! Oh, an be sure to post an
un decipherable test message as a challenge with a reward offered as
proof!
------------------------------
From: Anthony L. Celeste <[EMAIL PROTECTED]>
Subject: Re: Status of alleged *THIRD* key in MS Crypto API ?
Date: 3 Mar 2000 03:49:00 -0600
Reply-To: [EMAIL PROTECTED]
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED
"AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL
WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE...
Well, at least we know they stand behind their statements...
------------------------------
From: "Wesley H. Horton" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Can someone break this cipher?
Date: Fri, 03 Mar 2000 04:07:32 -0600
Well, let's think a moment.
You posted the challenge to the crypto news group on the 27th and no one
has broken it and returned your cipher text as yet.
Therefor:
It must be absolutely secure! Sure, encrypt whatever data you need to
keep sensitive using your system. No one will ever be able to break it.
I wouldn't bet my life or fortune on it personally though.
Wesley Horton
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Crypto.Com, Inc.
Date: Fri, 03 Mar 2000 11:20:04 +0100
Douglas A. Gwyn wrote:
>
> Ooo, I'm *so* impressed! I bet they're almost as reliable as CBS!
Thanks. I learn something from you here. I never have any contact with
CBS and other major US media. Since their names often appear in
newspapers I read, I 'automatically' (sort of intuitively) have
some 'respect' for them. Now I know it's essentially the same with
the politicians. Big publicity doesn't mean anything good at all,
but actually something very suspect.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Fri, 03 Mar 2000 11:19:53 +0100
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > Douglas A. Gwyn wrote:
> > > No, it was a simple statement of fact.
> > > When you repeat what you understand that I mean and it
> > > doesn't at all match what I meant, then you don't show
> > > signs of understanding my meaning at all.
> > > And the sarcastic tone you used convinced me that you
> > > weren't interested in understanding what I was saying.
> > > So it *is* a good idea to terminate the thread,
> > > because a discussion requires listeners as well as talkers.
> > Ah, 'one shows signs of understanding your meaning' if and only
> > if one 'agrees' with you, isn't that what you are saying above?
>
> No, again you pretend to repeat what I said but it doesn't match
> what I said. If you cannot summarize it accurately you have not
> understood it.
>
> > I would say that this is the viewpoint of a very 'naive' citizen
> > who believes that all officials in the government are 'gentlemen'.
>
> Well, you would be wrong yet again.
Simply saying your opponents are wrong is something any kid could
do in their talks. Clearly giving detailed and concrete reasons why
your opponents are wrong is what adult persons engaging in scientific
discussions do.
>
> > ... [long speech omitted] ...
>
> I've been explaining how the system *does* work, on the basis of
> first-hand knowledge of its workings, primarily to counter false
> accusations and to alleviate somewhat the public pressure to "do
> something" about an incorrectly perceived situation, which would
> not serve the public interest. Feel free to fantasize, but
> realize that that is what you are doing.
A claim based on something which one doesn't show or cannot show
(for whatever reason) does NOT have any value in scientific
discussions. WHAT were your 'first-hand' knowledge that you have
shown us in this thread? Please cite at least two concrete
sentences of your previous posts that clearly indicate that
you 'have been explaining that the system does work'. And please
say in what 'sense' do you really mean by the phrase 'the system
does work'. Do you simply mean that some systems (of 'any' kind)
exist and persons are employed by them and doing some work or
what?? And based on 'what' should one 'believe' that you indeed
have 'first-hand' knowledge? Were you previously an employee of an
interception network? (Otherwise you could only have 'second-hand'
knowledges, since no visitors are admitted to highly secret
environments.) Ah, I begin to speculate that I could one day well
understand why you have argued so fervently to 'prove' the innocence
and benevolence of such machineries.
M. K. Shen
==============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Wesley H. Horton" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Solitiare Algorithm/Math Question?
Date: Fri, 03 Mar 2000 04:16:56 -0600
Just a casual observation about solitaire:
If there are 54! ways of ordering a deck of cards, in a conventional
game of solitaire, with the cards laid out in a given pattern, how many
of those orderings would result in a winnable game. (assuming of course
that all moves were legal moves and all moves were the most logical play
available.)
I have to admit, that is a question that on its face (pun intended)
would seem to boggle the mind.
Regards,
Wesley Horton
------------------------------
From: [EMAIL PROTECTED]
Subject: Question about sort of signing
Date: Fri, 03 Mar 2000 10:09:20 GMT
Hello!
I have the following special problem that is somewhat related to
cryptography but perhaps not directly: I'd like to send messages to a
larger number of persons, and by nature of the channel I'm using,
everyone can eavesdrop in, but it's very hard for the eavesdroper to
alter or fake messages.
The messages are symmetrically encrypted, and (for now I want to assume)
only the recipients have the correct key--- in practice that will be
different, but that's another problem. On the channel, the eavesdropper
can also find a lot of irrelevant binary and plaintext data, as the
channel is a shared resource. The problem is: How can I make it easy for
me to recognize an encrypted message *without* using the key, but make it
as hard as possible for the eavesdropper to recognize it with *high*
certainty.
This may sound odd to you... fact is, that I do not really need an
encryption solution, but only one that requires an attacker to reverse-
engineer my software with a lot of waste of resources. Each message needs
a header that makes it very easy for my software to know almost for sure
that it's encrypted with my software. The eavesdropper can also be able
to recognize the message (since it's encrypted anyway, and he does not
have the key), but he may not be *certain* about it, so he cannot justify
censorship. I cannot use the key, since it's different for each <sender,
recipient>, but still every message header must be readable by my
program.
Maybe some kind of checksumming/hashing mechanism in the message header?
Or just using another key that is hardwired into my program? Or some sort
of steganography that spreads the header over the whole binary data, so
it's difficult to find without knowing the "steganographic secret"?
As you probably have recognized I'm playing with the idea of data
tunneling of some network protocols and infrastructures... any ideas?
Regards,
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Question about sort of signing
Date: 3 Mar 2000 10:53:14 GMT
My humble suggestion would be to apply ol' fashioned Hamming metric and
induce single bit errors according to a specific pattern in the encrypted
messages. You might e.g. use a generator matrix with 63 cols and 56 rows
(thereby increasing the bandwidth with a factor 63/56).
An attacker could, at least theoretically, use frequency analysis to find the
encrypted messages by looking for the expected 7 parity bits after each 56
bit message package, but that would take a while (to say the least) if you do
not use the normal form of Hamming generator matrices and maybe even exchange
the matrices dynamically.
In a previous article, < [EMAIL PROTECTED]> writes:
>Hello!
>
>I have the following special problem that is somewhat related to
>cryptography but perhaps not directly: I'd like to send messages to a
>larger number of persons, and by nature of the channel I'm using,
>everyone can eavesdrop in, but it's very hard for the eavesdroper to
>alter or fake messages.
>
>The messages are symmetrically encrypted, and (for now I want to assume)
>only the recipients have the correct key--- in practice that will be
>different, but that's another problem. On the channel, the eavesdropper
>can also find a lot of irrelevant binary and plaintext data, as the
>channel is a shared resource. The problem is: How can I make it easy for
>me to recognize an encrypted message *without* using the key, but make it
>as hard as possible for the eavesdropper to recognize it with *high*
>certainty.
>
>This may sound odd to you... fact is, that I do not really need an
>encryption solution, but only one that requires an attacker to reverse-
>engineer my software with a lot of waste of resources. Each message needs
>a header that makes it very easy for my software to know almost for sure
>that it's encrypted with my software. The eavesdropper can also be able
>to recognize the message (since it's encrypted anyway, and he does not
>have the key), but he may not be *certain* about it, so he cannot justify
>censorship. I cannot use the key, since it's different for each <sender,
>recipient>, but still every message header must be readable by my
>program.
>
>Maybe some kind of checksumming/hashing mechanism in the message header?
>Or just using another key that is hardwired into my program? Or some sort
>of steganography that spreads the header over the whole binary data, so
>it's difficult to find without knowing the "steganographic secret"?
>
>As you probably have recognized I'm playing with the idea of data
>tunneling of some network protocols and infrastructures... any ideas?
>
>Regards,
>
>Erich Steinmann
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
** 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
******************************
