Cryptography-Digest Digest #216, Volume #12 Thu, 13 Jul 00 00:13:01 EDT
Contents:
Re: Steganographic encryption system (Michael Rozdoba)
Re: Elliptic Curves encryption (Greg)
Re: Elliptic Curves encryption (Greg)
Re: Elliptic Curves encryption (Nicol So)
Re: Proposal of some processor instructions for cryptographical ("Douglas A. Gwyn")
Re: Crypto jokes? (potentially OT) ("Douglas A. Gwyn")
Re: Definition question ("Douglas A. Gwyn")
Re: cray and time needed to attack (Greg)
Re: cray and time needed to attack (Greg)
Re: Efficient Arithmetic Coding ("Douglas A. Gwyn")
Computing with Encrypted Functions (Austin Godber)
Re: Bit Shuffling ("Adam Durana")
Re: RC4-- repetition length? ("Scott Fluhrer")
Re: New Idea - Cipher on a Disk (Greg)
Re: DES Analytic Crack ("Douglas A. Gwyn")
Re: Q: Hadamard transform ("Douglas A. Gwyn")
Re: Base Encryption: Strongest Cypher (Boris Kazak)
Re: New Idea - Cipher on a Disk (Greg)
Re: Base Encryption: Strongest Cypher ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: Michael Rozdoba <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Thu, 13 Jul 2000 02:00:31 +0100
In article <[EMAIL PROTECTED]>, phil hunt
<[EMAIL PROTECTED]> wrote:
> On Wed, 12 Jul 2000 04:02:56 +0100, Michael Rozdoba <[EMAIL PROTECTED]>
[Snip]
> >Surely that depends on the definition of strong? If it merely means
> >hard to decrypt without the key, that doesn't contradict the statement
> >that the encrypted data is recognisable as encrypted data.
> Well, it seems to me that "strong" means that no-one can proctically
> find out any useful information about the plaintext if they know the
> ciphertext (obviously the size of the ciphertext file places a maximum
> limit on the complexity of the plaintext, but that should be it).
> If you can tell that the plaintext contains repeated blocks, that could
> help an adversary.
Ah, I think one of us has misunderstood Frank. You seem to have inferred
that one can identify repeats in the plaintext from the cipher text, while
I took him to mean one could spot repeats in the ciphertext (implying it
was cipher text & not noise) - hence my original comment below.
Perhaps I'm mistaken. It happens a lot.
> >> So how do I get it so it doesn't repeat?
> >
> >Do you need to? You were going to rely on the source being public to
> >prove it extends filesizes & thus a 25KB cipher text might legitimately
> >only contain a 1KB plain text. Would this not still work, as long as
> >the remaining data is not noise, but rather, is encrypted noise?
> I want the program to be as strong as possible, to give away as little
> as possible.
--
_ _
Michael Rozdoba ICQ: 15835336 |_| |_ | |_| i'm trapped | | |
Ashamed to belong to a club called ACNE | | |_ |_ | in reality ... o o o
mroz at ukgateway dot net // ......... homepage coming soon .........
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Thu, 13 Jul 2000 02:29:31 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> The P1363 password is easy to get, just ask for it, this allows them
to monitor
> usage.
> Don Johnson
>
I got a password and now I regret it. Why won't they just
make it freely available? I now get e-mail all the time
on ongoing conversations between other members of the group
that I don't care for. Perhaps it is easy to remove? But
it is really silly to begin with...
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Thu, 13 Jul 2000 02:30:05 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> The P1363 password is easy to get, just ask for it, this allows them
to monitor
> usage.
> Don Johnson
Also, I think the password might be MarsRoks or MarsRock or something
like that.
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Wed, 12 Jul 2000 22:43:11 -0400
Reply-To: see.signature
Greg wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (DJohn37050) wrote:
> > The P1363 password is easy to get, just ask for it, this allows them
> to monitor
> > usage.
> > Don Johnson
> >
>
> I got a password and now I regret it. Why won't they just
> make it freely available? I now get e-mail all the time
> on ongoing conversations between other members of the group
> that I don't care for. Perhaps it is easy to remove? But
> it is really silly to begin with...
Does applying for access automatically sign you up for their mailing
list?
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Wed, 12 Jul 2000 23:07:54 -0400
"Stefan Monnier " wrote:
> Of course, it's never been seriously considered because it would
> break a whole bunch of C code (since C specifies that sizeof(char)
> is 1 and people happily cast from integers and pointers all the time).
Casts are conversions and as such can involve whatever shifts,
masks, normalizations, etc. are necessary.
In fact, having bit addressability in the ISA doesn't change
the operation of C at all. The implementation simply won't
be using bytes smaller than an octet, since that is indeed
the lowest-common-denominator chunk size for data objects in
Standard C. One major reason that sizeof(char)==1 was wired
into the 1989 C standard was that there were no significant
ISAs in existence at the time that supported bit addressability.
I certainly argued for not imposing that requirement, which
unfortunately also got tied to the char-vs.-wchar_t debate.
(I suggested that "short char" be the minimal chunk and that
it be allowed to be as small as 1 bit. Let's please not rehash
here the pros and cons, since it is too late to change this for
C anyway.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Crypto jokes? (potentially OT)
Date: Wed, 12 Jul 2000 23:11:33 -0400
Steve Meyer wrote:
> How about claim by BBC television producer that English spy ageny
> discovered public key cryptography. Probably in joke that one must
> attend IACR conference to appreciate.
I didn't understand your joke. Is it that you really are unaware
that nonsecret-key encryption had in fact been invented before RSA?
(However, it wasn't much exploited.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Definition question
Date: Wed, 12 Jul 2000 23:17:52 -0400
Ichinin wrote:
> - Would it be right to say that the sciense of cryptology
> would be to try to "construct that randomness without
> having to resort to OTP's"?
No. That is only a small part of cryptology, and for many
applications not even an important part.
> - Would it be possible to measure it's cryptographic
> strenght by analysing the output from a cipher
> (say, encrypt 0xfffffffff..ffff etc) by running it
> through programs that test randomness?
No. The best general statistical tests (not quite "for
randomness", although that is close enough) cannot detect
some forms of cryptographic weakness.
> - Which would be more desirable; that the KEY is random
> or that the CIPHERTEXT OUTPUT appear to be random?
It depends on details. If the key is not sufficiently
random then it might be possible to guess it with a
reasonable chance of success. The ciphertext doesn't
have to look particularly random, although when it takes
the *same amount of storage as the plaintext* then that
is generally a desirable property (but not the main one).
> - Would it be possible to test (*see below) which set of
> cryptographic components that would be best suitable
> to get *that* randomness one is requiring? ...and for
> any particular plaintext?
I don't understand the question, but the answer is no.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Thu, 13 Jul 2000 03:06:21 GMT
> I think Cray's are over rated.
I am no expert, so if you can answer this I would really like
to know the answer- how many PCs running a 1GHz RISC would it
take to come near a Cray T90:
Up to 32 processors and nearly 60 GFLOPS of peak
performance offer the highest sustained-to-peak
performance on a wide range of supercomputing
applications.
Nearly 1TB of memory bandwidth speeds overall
processing 512 to 16,384MB of central memory
gives customers expandable memory options for
their varying workloads.
Aggregate I/O bandwidth of more than 30GB/per
second, provides fast delivery of solutions to
users.
64-bit IEEE floating-point CPU improves
interoperability with engineering workstations.
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Thu, 13 Jul 2000 03:08:18 GMT
> > 4� 1024 bit key with DH
>
> This borders on being theoretically possible with present technology,
> but the attacker would have to be willing to dump millions of dollars
> into the project, and even at that it would NOT be completed very
> quickly -- think in terms of years, not months.
If I poured in $100M, how quick could I get the key and what would
that key "generally" give me in return?
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Efficient Arithmetic Coding
Date: Wed, 12 Jul 2000 23:25:20 -0400
"SCOTT19U.ZIP_GUY" wrote:
> Actually it was a thread about efficient Arithmetic Coders in
> C or C++.
That's also the way I read the question. Maybe brevity isn't
always a virtue..
------------------------------
From: Austin Godber <[EMAIL PROTECTED]>
Subject: Computing with Encrypted Functions
Date: Thu, 13 Jul 2000 03:20:53 GMT
Hello,
I have recently come across an article on computing with encrypted
functions by T. Sander and C. Tscudin called "Protecting Mobile Agents
Against Malicious Hosts".
I have tried to find some additional references along these lines but
have only found very few. (One from C. Cachin ... IBM Zurich and an
older one from A.C. Yao). I was wondering if anyone here is familiar
with this topic and if there is any current research I can look into.
For those who aren't familiar with this here is a good summary I found
on the web:
"The idea is to encrypt a function f to obtain some other function E(f)
that hides the function f. This encrypted function can then be
implemented as a program P(E(f)), which is interpreted as a mobile
agent and sent to the agent executor. The latter can execute the mobile
agent P(E(f)) on an input value x, which leads to the encrypted result:
P(E(f))(x). Since the agent executor does not know what function it
actually computed, it can not meaningfully tamper with the code or its
execution and is restricted to random modifications (which result in
denial-of-service) and replay attacks. The encrypted result is returned
to the agent owner who can apply the decryption function, that only he
knows, to obtain the desired result of the function f applied to the
input value x: E^1(P(E(f))(x)) = f(x)."
Thanks
Austin Godber
[EMAIL PROTECTED]
PS - I have URLS for most of the above mentioned sources.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Bit Shuffling
Date: Wed, 12 Jul 2000 23:29:02 -0400
This is a total rip off of something I posted early in 1999. I called it
"slotting" and the only difference between what you present here and what I
posted is that yours works with 1 bit of the key per byte of input, while
mine worked with 1 bit of the key per 1 bit of the input. This method is
totally linear, X number rounds of this could be broken with one ciphertext
and the corresponding plaintext. And as for your patent, it was already in
public domain before you posted this. It is not even worth patenting, since
it is so weak. If you would like to see the original idea look at
http://www.nine.net/~adam/slotting.html
- Adam
> p.s.: I have a patent pending on this.
>
> SHUFFLE
> -------
>
> Original block : a b c d e f g h i j
>
> Key : 1 0 1 1 1 0 0 1 0 1
>
> Block 1 : a c d e h j
>
> Block 2 : b f g i
>
> New Block : a c d e h j b f g i
>
>
> The bits from the "Original block" are
> moved to "block 1" if the corresponding
> key bit is "1" and to "Block 2" if the
> corresponding key is "0".
>
> The new block is formed by concatenating
> the "Block 1" and "Block 2" together.
>
> UNSHUFFLE
> ---------
>
>
> 1) Count of number of "1s" (=n1) in the key.
> 2) Split the data block into two blocks
> by placing the first n1 bits into "Block 1"
> and remaining bits into "Block 2".
>
> 3) Loop over all key bits (left to right)
> if the key bit is "1" move the bit from
> "Block 1" to the "New Block" and if it
> is zero them move the bit from the
> "Block 2" to the "New Block".
>
>
> Key : 1 0 1 1 1 0 0 1 0 1
>
> this gives n1 = 6;
>
>
> original block : a c d e h j b f g i
> ^
> |
> split here
>
> Key : 1 0 1 1 1 0 0 1 0 1
>
>
> Block 1 : a c d e h j
> Block 2 : b f g i
>
>
> Block 1 : a c d e h j
> (occupy '1' pos)
>
> Block 2 : b f g i
> (occupy '0' pos)
>
> New Block : a b c d e f g h i j
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Date: Wed, 12 Jul 2000 20:20:24 -0700
Bill Unruh <[EMAIL PROTECTED]> wrote in message
news:8kgev7$nse$[EMAIL PROTECTED]...
> What is the repetition length of the RC4 cypher? is it 256! (the number
> of states of the matrix) or 256^2 256! (the number of states of the
> matix times the number of different states of the counters) or something
> much less than these? Are any keys known to give a short rep length or
> do all keys produce the same (ie a traversal over all possible
> permutations)?
The only serious analysis I know about this is in:
S. Mister, S. Tavares, Cryptanalysis of RC4-like Ciphers, in the Workshop
Record of the Workshop on Selected Areas in Cryptography (SAC '98), Aug.
17-18, 1998, pp. 136-148.
It's been a while since I looked at it, but IIRC they show that the entire
cycle length is likely to be considerably smaller than the 256! * (256)^2
maximum, and likely to depend on initial key. They also show how to
rederive the state of the permutation if you have a sizable portion of a
cycle.
--
poncho
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk
Date: Thu, 13 Jul 2000 03:26:55 GMT
> Greg wrote:
>
> > I was looking over a thread on the question of adding hardware
> > support to a CPU. The problem there is that the CPU must be
> > flexible enough to support various types of ciphers if you go
> > that route.
> >
> > What if a disk drive came with a cipher on the disk, and supported
> > a new ATA instruction set that took advantage of these ciphers?
> >
> > The cipher can be very specific for that disk drive. It can be
> > a FEATURE of the disk drive, much like transfer speeds and buffer
> > sizes are marketing features. The cipher can be strong. The disk
> > drive manufacturers would compete for cipher strength and speed,
> > much like they do now for transfer speed. All of the software
> > is eliminated and this feature is completely transparent. There is
> > no CPU overhead. Multiple disks can work independently of each
> > other.
> >
> > Sounds like a great idea for Fujitsu and IBM to incorporate into
> > their drives! But, alas, I proposed it here in the public domain...
>
> Key management is the key ;-)
> How do you propose to manage the keys used by the drive's cipher(s)?
Let's try this-
- You enter a password into a BIOS startup screen
- the disk creates a key from the password
- if the disk is not currently encrypted, then
- the disk throws out the key and runs in unencrypted mode
else
- the disk takes the key and uses it for all traffic to
and from the platters
At some point, a user will want to START using encryption.
To change from unencrypted to encrypted, a command is given
by the software or BIOS firmware to take a password, create
a key, and encrypt the entire disk. After this, the disk
is encrypted. To go back to an unencrypted format, the same
is done but with a null password. To change encryption keys
one must decrypt with the old key then encrypt with the new key.
Does that answer your question or did I miss what you were
getting at?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: DES Analytic Crack
Date: Wed, 12 Jul 2000 23:42:35 -0400
Mok-Kong Shen wrote:
> It seems that it could be advantageous to first try the diverse
> ideas out on a miniature version of DES to gain experiences of
> which methods are the best.
No, absolutely not -- I am tired of solutions for "toy problems"
that do not scale. The whole point of the exercise was to develop
a technique that would be effective against a large class of real-
world cryptosystems. If one doesn't start out with that goal,
most likely any simplified approach that didn't have to address the
tough problems brought on by combinatorial explosion would not
work when applied to the real problem where such matters pose
the biggest part of the problem!
The sketch I gave wasn't a set of diverse ideas; it was essentially
all the steps one would use in that one particular method, except
for specific techniques to use in tree reduction. The only
diversity was that two methods were suggested for the final stage
(iterative reestimation vs. gradient following).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Q: Hadamard transform
Date: Wed, 12 Jul 2000 23:43:36 -0400
Mok-Kong Shen wrote:
> One maybe odd question I would like to know is whether one
> would get something inherently different in quality, if, instead of
> doing 1-D Hadamard transform of n^2 values, one fills these
> into a matrix of n*n and process that with a 2-D transform.
What problem are you trying to solve? Why 2 dimensions instead
of 64?
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Base Encryption: Strongest Cypher
Date: Thu, 13 Jul 2000 03:45:44 GMT
[EMAIL PROTECTED] wrote:
>*************************(snip)
> Base Encryption
>
> Main Strengths:
> 1) Immune from plain-text-attacks.
> 2) Immune from brute-force-attacks.
> 3) As secure as OTP
> 4) Can utilize throwaway algorithms.
> 5) Dynamic Algorithms (operators and operations)
> 6) Dynamic Base (symbol set)
> 7) Plug-And-Play engine (other cyphers can be augmentated to it)
******************(snip)
> 4) Dynamic algorithms.
> Operator and Operations can be changed on the
> fly. And can be created from scratch using basic building blocks or
> use other pluged in cypher.
********************(is #6 different from #4? )
> 6) Dynamic Algorithms (operators and operations)
> Algorithms can be created from scratch, and is not static.
>
> 7) Dynamic Base (symbol set)
> swappable symbols and arbitrary symbol sets.
******************(snip)
> Where can I find more info about Base Encryption?
> http://www.edepot.com/phl.html
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
========================
Dear Po-Han Li:
Will you please clarify some points about your cipher?
1. Whatever the number base (or symbol base) will be used for
your cipher, I believe that you are going to do actual encryption and
decription in a computer. In this case computer will convert all your
Base Representations back to binary.
Or are you proposing another version of paper-and-pencil
cipher? Why then the SuperCalc and all complicated programming?
2) Symbol Remapping is known since Caesar (you admit it yourself).
What is the big point of using this monoalphabetic method?
3) If you are going to send some ciphertext to your (girlfriend?),
you must pass her information about:
Original plaintext base (ASCII, ANSI, base 26, KOI-8, base 36, base
52,
or whatever else).
New base for transformation.
The table for symbol remapping.
Encryption algoritm (how to choose among the many "dynamical" ones).
And some kind of Message Authentication so that she would be sure
that the message was not changed underway.
How big a key will be needed in order to pass her all this
information
securely? How will you encrypt the key so that it will not be stolen?
Nowhere in your "system" I saw these question raised (let alone
answered).
Best wishes BNK
P.S. (off record) You seem to be fascinated with the complexity and
variability of your cipher, to the extent that it starts resembling an
obscession and an "idee-fixe". While you still keep some reason in
your head, please go consult with a psychiatrist.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk
Date: Thu, 13 Jul 2000 03:42:21 GMT
> >Key management is the key ;-)
> >How do you propose to manage the keys used by the drive's cipher(s)?
> That is a tricky issue. Do you want one password/drive or multiple?
> Do you want to divide the disk into virtual drives and then a
> password for each (the easy way out).
Like other onboard components, a cipher knows only a hard drive,
not the data written on the drive to make virtual drives.
> The SCSI interface seems a better way to go since IDE does
> not support multiple devices per controller.
Like on board buffers, faster rotation speeds, smaller sizes
and faster data transfer rates, on board ciphers would find
their way on both and the IDE market would be better at first
where low end home PCs can use them and people can have some
additional sense of security for say $30 more.
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Base Encryption: Strongest Cypher
Date: Wed, 12 Jul 2000 23:54:34 -0400
Boris Kazak wrote:
> P.S. (off record) You seem to be fascinated with the complexity and
> variability of your cipher, to the extent that it starts resembling an
> obscession and an "idee-fixe". While you still keep some reason in
> your head, please go consult with a psychiatrist.
Confusion of complexity and security is quite common, especially
among neophytes. If there is a psychiatric issue, it is more one
of believing that there is no need to learn the basics of a field
before jumping in and telling everyone how things should be done.
Examples of this can be found on the Web for almost any field.
------------------------------
** 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
******************************
