Cryptography-Digest Digest #427, Volume #14 Thu, 24 May 01 23:13:01 EDT
Contents:
Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... Am I a fool ?
("Paul Pires")
Re: rs232 data encryption ("Tom St Denis")
Help with JAVA code for octet string (Sam)
Re: Medical data confidentiality on network comms ("Kathleen Chapman")
Re: Evidence Eliminator Detractors Working Hard But No Result? (Frog2)
Re: Help with JAVA code for octet string ("Jeffrey Walton")
Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... Am I a fool ?
("BenZen")
Re: rs232 data encryption ("Scott Fluhrer")
Re: Help with JAVA code for octet string ("Brian McKeever")
----------------------------------------------------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... Am I a
fool ?
Date: Thu, 24 May 2001 18:07:51 -0700
BenZen <[EMAIL PROTECTED]> wrote in message
news:zBhP6.514$[EMAIL PROTECTED]...
<Snip>
> The main difficulty is finding a Fractal algorithm, that insures sufficiently VAST
> domain for seeds (like a random-number-generator)... And that we can insure
> 1) it won't become periodic.
For how long? This is a deterministic process right? It must repeat sooner or
later. Don't you mean "for a really long time"?
> 2) The content statistics matches as closely as possible, ZIP bit distributions.
>
> Then I need a TOOL, technique to demonstrate my algorith works...Lyapunov ?
>
> I don't plan on using a simple mapping of a common Mandelbrot graphic.
> I plan on finding a Fractal sequence generator with the proper statistical output,
> by trunkating the fractal surface.. Think of a fractal with depth instead of colors.
> Then if I truncate it (we also do this with colors); I get an additionnal parameter,
> which is the SPEED at which it wants to evade. I used to use this factor to add
> some depth to my fractal images... But now this value, could be used to 'control',
> the fractal 'sampling' in the 2D C domain.
>
> My point is:
> One way or the other; Me, or another smarter matematician shall find such a
> simple algorithm, based on Fractals but not necessarily 'pure'.. Maybe add some
> 'Strange Attractors' to map the Fractal domain... I'm just wild imagination here.
>
> ... Then when the sequence is tested against statistical models for demonstration.
> .... Then it's 100% Safe Fractal based encoding.
>
> It's just a matter of time.. I just don't see any problem.
> Hence the question: Am I a fool ?
> IMHO, pseudorandom, is just bound to fail, as a pale imitation of Fractal+Chaos.
Fail how? Be insecure? I don't see how you jump to that conclusion. Why isn't
your concept for producing "Fractal+Chaos" Not a pseudo random function?
There are some fine points to the advice that you were given that I think you
might have blown by.
There might be a whole bunch of "100% Safe encoding schemes" now, the
problem is knowing and proving it. Check out Claude Shannon and Perfect
Secrecy.
Testing determines that a sample does not have the detectable bias that the test
was meant to measure. It does not determine that a sample is good. New
methods need new tests. There is no way to develope an exhaustive set of tests.
The degrees of freedom, the number of ways it could be biased are just too big.
(Trust me, I just learned this the hard way) Thank's Scott.
Keys and keyspace, Any key which could be selected needs to be uniformly
distributed amongst the possible keys. It seems that you are saying that the
number of good keys is large. It needs to be that a Key chosen will be a
good key from a large group of good keys.
Choosing the characteristic of a generator to specifically offset the known
bad charateristics of the plaintext (zipfile) sounds like a remarkably bad thing
to do. Perhaps if I ever get this stuff, I'll know why :-) Anybody care to help
me out here?
Paul
>
> Please give me your thoughts,
> And I would appreciate some tips on how to verify if my algorithm generates
> a sufficiently (random/chaotic) sequence.
> [EMAIL PROTECTED]
> Ben Zen
>
>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: rs232 data encryption
Date: Fri, 25 May 2001 01:30:36 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:9ekavs$s5m$[EMAIL PROTECTED]...
>
> Robert Self <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > I have a 38Kbaud rs232 data stream that I would like to encrypt and
> > decrypt on the other end in real time. I also need to have the
> > receiver be able to rapidly get back in sync in case of bad data. Does
> > anyone know of a fairly secure algorithm to do this? It needs to be
> > fast since it needs to run in real time on a pc and on a
> > microprocessor.
> Well, unless the microprocessor you're using is seriously slow (or
seriously
> loaded with other tasks), you can use AES CFB mode with a block shift of 8
> bits. This is (in C-like pseudocode):
>
> Encryption Process:
>
> byte Encrypt( byte Plaintext ) {
> byte Result = Plaintext ^ Encrypt( State );
> State = (State << 8) | Result;
> return Result;
> }
>
>
> Decryption Process:
>
> byte Decrypt( byte Ciphertext ) {
> byte Result = Ciphertext ^ Encrypt( State );
> State = (State << 8) | Ciphertext;
> return Result;
> }
>
> (where State is a 16 byte internal variable, and the result of Encrypt is
> implicitly reduced to 8 bits).
>
> This will do 1 AES encryption per byte sent (which, in your application,
> means at most 4000 block encryptions per second). In addition, after an
> arbitrary error, it will resync after 16 bytes (as long as byte boundaries
> are respected, which you can assume with RS-232).
>
> The most severe security problem is that, if the attacker wants to make
> specific modifications to a particular byte, and doesn't care what happens
> to the decrypted plaintext immediately afterwards, he can flip bits in the
> ciphertext byte. This will flip the corresponds bits in the decrypted
> ciphertext byte, and engibberish the next 16 bytes of decrypted plaintext.
> Whether this is a serious concern depends on the protocol, and the attack
> model.
I don't want to sound like a CTR nut-case, but CTR mode wins here too. It
doesn't require one encryption per byte and is much simpler to analyze then
CFB.
Again I feel CTR mode will win over CBC and CFB. Specially in this case
since the low end cpu can do a single encryption per 16 bytes and still gets
the benefits of sending partial blocks and avoiding errors from killing the
entire stream.
Tom
------------------------------
Date: Fri, 25 May 2001 11:46:05 +1000
From: Sam <[EMAIL PROTECTED]>
Subject: Help with JAVA code for octet string
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Can some body help me by giving few lines simple JAVA code for converting
plaintext to octet string
<p>* like in rfc 2313 PKCS1v1.5
<br>D= plaintext, PS = padding, BT = block type, EB = output octet
string
<br>EB = 00 || BT || PS || 00 || D
of length equal to modulus lengths in octets
<p>BT block type = 01 for private and 02 for public
<br>PS padding string = (for BT=01) = FF
<br>
= (for BT=02) = pseudorandomly gemnerated octet
<p>Also JAVA code for converting Octet String to integer and Integer
to Octet string
<p>Thanks in advance
<br>Sam</html>
------------------------------
From: "Kathleen Chapman" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Fri, 25 May 2001 01:54:03 GMT
> Harris Georgiou wrote:
> >
> > I'm currently working on some distributed medical image analysis &
> > diagnostic system and I was wondering: what security issues (if any) are
> > addressed by modern medical LAN/RDBMS systems used by hospitals or
> > insurrance companies?
Harris,
I didn't catch your original message, but if organizations in the United
States may be using your application, it's got to meet HIPPA security
requirements. HIPPA stands for Health Insurance Portability and
Accountability Act. One part of it is to set national standards for
electronic transmission of claims, enrollment, eligibility, payment, and
other information. Another part is to set standards for the security of
health information systems. Here is a link to the Information Technology
Association of America's HIPPA page:
http://www.itaa.org/isec/ehealth/hippa.htm
Kathy
------------------------------
From: Frog2 <[EMAIL PROTECTED]>
Date: 25 May 2001 01:59:54 -0000
Subject: Re: Evidence Eliminator Detractors Working Hard But No Result?
Crossposted-To: alt.privacy,alt.security.pgp
Here's some results for you, lying cheating stealing scumbags.
Evidence so-called Eliminator does a fixed pattern 3 pass "wipe".
All ones, all zeroes, then a "random" pattern on top. Anyone
with a storage oscilloscope and schematics for the hard drive
they are examining, can quickly and easily recover 100% of the
data overwritten by EE. That's every computer forensics lab
in the world, and every electronics engineering company in the
world.
The FBI's computer forensice lab cost over sixty million dollars
and you can bet your life that data "eliminated" by EE is 100%
visible to them the moment they plug a seized hard drive into
a test bed. Likewise for other countries: The first time
they encounter EE in a case, it will cost them a modest amount of
time and money to recover the "eliminated" files, but from then
on, recovering data deleted by EE costs nothing but a couple
hours routine lab time using the equipment and software left over
from the 1st EE case.
Robin Hood Software has never paid for a third party audit of
their crap, and they never will, because they know what the
results will be. But they can lie all they want to for free.
Something's rotten in Nottingham. Mssrs. A.S. Churchill, and
R.H. Ride, of Robin Hood Software Ltd., the makers of Evidence
Eliminator, are nothing more or less than thieves. Robin Hood
Software robs from its customers, and gives to itself. They also
rob from every Usenet server in the world, by blatantly
advertising their crap in thousands of newsgroups, in direct
violation of terms of service and community standards.
Don't bother reporting their spamming through normal channels.
Churchill & Ride's ISP is their business partner, supports
and encourages their spamming, and also knows perfectly well that
Evidence Eliminator is worthless shit. Ask their sponsoring
ISP's CEO, Mr. Richard Drage of Proweb (UK) Ltd: Is he really
making enough money from Evidence Eliminator to compensate him
for becoming internationally known as a sleazy fly by night
scumbag? Is he getting rich fast enough that he doesn't care if
he never works in the IT world again? Evidently so.
Con men don't care what other people think: "We are so smart
and you are so stupid," is their way of looking at the human
race. Every time they sell another copy of EE to an unsuspecting
mark, they consider their position proven again.
Why haven't I heard the words USENET DEATH SENTENCE in
connection with this spam-spraying monster called Proweb Ltd? As
the primary source of EE spam and the only ISP that makes a
profit from Usenet's all time number one spammer, Proweb has it
coming, in spades.
Please write to your ISP, describe the problem, and request
that Proweb (UK) Ltd be banned from uploading, downloading,
or relaying through your ISP's news servers. If you don't
feel like writing a letter yourself, send a copy of this post,
with a couple of lines indicating your agreement.
Send a copy of your message to abuse.net, so that your
contribution can be added to the already large collection of
complaints about Evidence Eliminator's unethical and in some
jurisdictions illegal spamming activities, sponsored and
encouraged by Proweb Ltd. Proweb is the irresponsible ISP
spearheading a de facto campaign to establish that Usenet spam is
a normal and profitable business practice. Usenet does not need
Proweb's "contribution", and they have certainly earned exclusion
from access to Usenet's contents.
Usenet death sentence. Proweb (UK) Ltd. It's the right
thing to do. Anything else makes every Usenet provider
the knowing accomplice of thieves.
------------------------------
Reply-To: "Jeffrey Walton" <[EMAIL PROTECTED]>
From: "Jeffrey Walton" <[EMAIL PROTECTED]>
Subject: Re: Help with JAVA code for octet string
Date: Thu, 24 May 2001 22:29:54 -0400
http://www.javaworld.com/javaworld/javatips/jw-javatip36-2.html
You might try various search engines with the following keywords:
+java +"octet stream" +convert -codetype
"Sam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
Can some body help me by giving few lines simple JAVA code for
converting plaintext to octet string
* like in rfc 2313 PKCS1v1.5
D= plaintext, PS = padding, BT = block type, EB = output octet string
EB = 00 || BT || PS || 00 || D of length equal to modulus
lengths in octets
BT block type = 01 for private and 02 for public
PS padding string = (for BT=01) = FF
= (for BT=02) = pseudorandomly gemnerated
octet
Also JAVA code for converting Octet String to integer and Integer to
Octet string
Thanks in advance
Sam
------------------------------
From: "BenZen" <[EMAIL PROTECTED]>
Subject: Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... Am I a
fool ?
Date: Thu, 24 May 2001 22:33:46 -0400
Paul Rubin wrote in message <[EMAIL PROTECTED]>...
>"BenZen" <[EMAIL PROTECTED]> writes:
>> Then I decided it would be fun to use a 'Fractal' sequence
>> instead of a simple binary pattern induced by the password.
>
>That turns out to be kind of a dumb idea.
>
You are a harsh judge my friend ;)
> Fractals are cool because they give rise to pictures with interesting-looking
>structure.
> But cryptographic output should have NO apparent structure. So the goals
>of cryptography and fractals are incompatible. (Note: I didn't think
>that up--I think it's mentioned in the sci.crypt FAQ).
>
FAQ or no FAQ;
At one time people thought the earth was flat.
Fractals are cool because we see pretty pictures is just as ignorent
as in the 19'th century when they used electricity to amuse the crowds.
Fractal is a much deeper property of the Mathematical operations,
and algorithmic onto this... You must unlearn what you have learned I think Paul.
Why fractals you still wonder ?.
And you think it's a disadventage to have some structure in a numerical sequence.
Then I might offer you an answer to this.
First: The fractal mapped in a 2D visual environment clearly demonstrate
two important properties. First of which is the 'complexity' and seemingly
infinite depth to this complexity near the 'chaotic' regions.
A) This complexity shall answer the first need of a good numerical sequence for
encoding purposes... Huge Complexity in determining what is to follow.
I can almost safely presume it shall be easy to prove impossible to predict,
using a variant of the fractal equations/algorithms.
B) The strong internal 'homothetic' property of fractals, is a visually intuitive
sign that keeps the mind wondering if there is some sort of 'intelligence'
behind this... It looks structured, and has a nature-like feel to it.
* That shall help very much in my view; Because it shall also better 'MATCH',
any apparent 'structure' of a document/binary, anything with a iota of
structure.
This match will in my view, help mask each-other's statistics making the
'apparent' structure of Fractals Hide the apparent structure of our document.
* ALSO; this homothetic property makes it difficult to determine at what
level of 'zoom' you are inside the fractal itself. Which makes it virtually
impossible from an outsider, to locate the given fractal sequence within
a given set..... It's like being lost in a forest that looks all too familiar.
>You're best off using an existing encryption algorithm like AES (Rijndael).
>
Yeah, the easy way.
That's how the Government like things; They can use brute force or
some hidden flaws in this algorithm and keep an eye on everyone.
Thanks for your suggestion anyway Paul.. I do appreciate.
I am just convinced right now that modified Fractal will provide the solution
sooner or later.
Best regards,
Ben
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: rs232 data encryption
Date: Thu, 24 May 2001 19:44:35 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:0BiP6.30577$[EMAIL PROTECTED]...
>
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> news:9ekavs$s5m$[EMAIL PROTECTED]...
> >
> > Robert Self <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > I have a 38Kbaud rs232 data stream that I would like to encrypt and
> > > decrypt on the other end in real time. I also need to have the
> > > receiver be able to rapidly get back in sync in case of bad data. Does
> > > anyone know of a fairly secure algorithm to do this? It needs to be
> > > fast since it needs to run in real time on a pc and on a
> > > microprocessor.
> > Well, unless the microprocessor you're using is seriously slow (or
> seriously
> > loaded with other tasks), you can use AES CFB mode with a block shift of
8
> > bits. This is (in C-like pseudocode):
> >
> > Encryption Process:
> >
> > byte Encrypt( byte Plaintext ) {
> > byte Result = Plaintext ^ Encrypt( State );
> > State = (State << 8) | Result;
> > return Result;
> > }
> >
> >
> > Decryption Process:
> >
> > byte Decrypt( byte Ciphertext ) {
> > byte Result = Ciphertext ^ Encrypt( State );
> > State = (State << 8) | Ciphertext;
> > return Result;
> > }
> >
> > (where State is a 16 byte internal variable, and the result of Encrypt
is
> > implicitly reduced to 8 bits).
> >
> > This will do 1 AES encryption per byte sent (which, in your application,
> > means at most 4000 block encryptions per second). In addition, after an
> > arbitrary error, it will resync after 16 bytes (as long as byte
boundaries
> > are respected, which you can assume with RS-232).
> >
> > The most severe security problem is that, if the attacker wants to make
> > specific modifications to a particular byte, and doesn't care what
happens
> > to the decrypted plaintext immediately afterwards, he can flip bits in
the
> > ciphertext byte. This will flip the corresponds bits in the decrypted
> > ciphertext byte, and engibberish the next 16 bytes of decrypted
plaintext.
> > Whether this is a serious concern depends on the protocol, and the
attack
> > model.
>
> I don't want to sound like a CTR nut-case, but CTR mode wins here too. It
> doesn't require one encryption per byte and is much simpler to analyze
then
> CFB.
CTR mode doesn't automatically resync after add/drop errors (and with a
noisy RS-232 line, they happen). You could add explicit resyncing, but a)
that chews up bandwidth, b) that adds extra logic, and c) you also have to
worry about "what happens if the resync pattern just happens to occur in the
ciphertext"
There was a paper at FSE2001 by Alkassar et al about a CFB variant that
retained the resyncing property, but drastically reduced the expected number
of encryptions. However, I thought that the OP would prefer an
"off-the-shelf" solution, and in any case, 4000 block encryptions per second
is not pushing the state of the art, even with a moderately old
microprocessor. Of course, if it's an 8051, it probably isn't particularly
doable...
>
> Again I feel CTR mode will win over CBC and CFB. Specially in this case
> since the low end cpu can do a single encryption per 16 bytes and still
gets
> the benefits of sending partial blocks and avoiding errors from killing
the
> entire stream.
CFB can handle partial blocks as well, and again, cannot resync from
add/drop errors.
--
poncho
------------------------------
Reply-To: "Brian McKeever" <[EMAIL PROTECTED]>
From: "Brian McKeever" <[EMAIL PROTECTED]>
Subject: Re: Help with JAVA code for octet string
Date: Fri, 25 May 2001 03:06:34 GMT
"Sam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>Can some body help me by giving few lines simple JAVA code for converting
plaintext to octet string
[snip]
>Also JAVA code for converting Octet String to integer and Integer to Octet
string
Well, it's not really clear exactly what you want, since "Octet string" is
not an accepted Java term, AFAIK. If you want a byte array, use the method
byte[] String.getBytes(). Again, assuming Octet string == byte array, you
can make an int out of 4 bytes by shifting and oring, and you can reverse
the process to go the other way.
If this is not what you want, I think you'll have to learn enough Java to
determine what it is that you do want.
Brian
------------------------------
** 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
******************************
