Cryptography-Digest Digest #209, Volume #12 Wed, 12 Jul 00 01:13:01 EDT
Contents:
Base Encryption: Strongest Cypher ([EMAIL PROTECTED])
Re: Steganographic encryption system (jungle)
Re: Proposal of some processor instructions for cryptographical applications
("Stephen Fuld")
Re: Steganographic encryption system (jungle)
Re: Steganographic encryption system (jungle)
Re: OTP's again ("Trevor L. Jackson, III")
Re: Base Encryption: Strongest Cypher ("sbh78")
Re: OTP's again (Mack)
Re: bank vault security (was Re: SecurID crypto (was "one time passwords ("Trevor
L. Jackson, III")
Re: Elliptic Curves encryption (Mack)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Base Encryption: Strongest Cypher
Date: Wed, 12 Jul 2000 04:08:59 GMT
The following describes the main features of Base Encryption.
I will try to address legitimate points made by other in previous
posts. For the rest, I suggest you seriously read the paper and
understand it before making comments. Childish attacks covering
up an inherent fear, or those that simply still don't get it,
will simply be ignored (you know who you are). Read the previous
Advanced Encryption FAQ if you are still having a difficult time
sitting down and admitting the truth about Base Encryption.
I have yet to find someone who can find a fault with Base Encryption.
I have yet to find someone (maybe one, and I am addressing it here) who
came close to making a scholarly comment on it.
Is everyone here a reflection of the analytical abilities of the
encryption community? I certainly hope not. I guess text-book
trained minds can't think outside of the box. Come on, I challenge
you: make a scholarly analysis of it with references. I have yet
to find a post from someone who can really think, who can use their
brains and not trapped behind a big ego.
More info: http://www.edepot.com/phl.html
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)
1) Immune from plain-text-attacks.
It is immune from plain-text-attacks because multiple algorithms
can generate same plaintext. Multiple algorithms can generate
same cyphertext. It is like saying how many ways are there to
come up with 12345? (infinite: 12344+1, 12343+2, 1+1+1+12342, etc)
2) Immune from brute-force-attacks.
It is immune from brute-force-attacks. A lot of pepple on this
forum simply do not understand this. Read the Garage Door example,
then the Chinese Newspaper, then come back to me. It is exponentially
expensive. Then when you come back to me, and STILL don't get it.
Get this...
You don't know when you have the correct key. There is no way to
find out. Because multiple algorithms can generate a text, you have
no way to verify you have the correct key. So you can permutate the
hard way, starting with 1 bit, then to 256 bits. Going through
the values for EACH bit increase (rather than the current weak cypher's
starting point at 256 bits (value 0) and end at 256 bits (value 256).
Then after you permutate through all the keys, you have NOTHING!!!
You don't know when you have found the answer. It is immune from
brute-force-attacks on the basis the INABILITY for you test against
the engine and know when you have the right key.
3) MORE secure as OTP.
For those that still dont "get it". Here is a clue: Think of
each piece of paper on the pad as a dynamic algorithm in Base
Encryption.
Now, you can use plain text attack on that piece of paper on the One
Time Pad. Can you do that on Base Encryption? NO.
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.
5) Can utilize throwaway algorithms.
Yes folks: As revolutionary as it sound!!
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.
8) Plug-And-Play engine (other cyphers can be augmentated to it)
Yes, very modular.
9) Web-centric
The engine need not reside on your client but diffused through
the internet. Dynamic algorithms can be generated from dynamic
content from websites.
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.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Wed, 12 Jul 2000 00:21:33 -0400
or explaining why 30 kb will decrypt into 2 kb plaintext might keep him busy
forever ...
silly concept doesn't work ...
John Winters wrote:
>
> In article <[EMAIL PROTECTED]>,
> phil hunt <[EMAIL PROTECTED]> wrote:
> >On 10 Jul 2000 19:59:28 +0100, John Winters <[EMAIL PROTECTED]> wrote:
> >>In article <[EMAIL PROTECTED]>, jungle <[EMAIL PROTECTED]> wrote:
> >>>phil hunt wrote:
> >>>> I am thinking of developing a steganographic encryption system that
> >>>> will enable a particular cyphertext to be decrypted into two or more
> >>>> different plaintexts, depending on which key is used. (Provisionally
> >>>> named 'stes'). To be more precise:
> >>>
> >>>your concept doesn't work ...
> >>>you can't create system that will work on principle that ...
> >>>
> >>>24 decrypts into 20 or/and 21 or/and 22 or/and 23 or/and ...
> >>>[ number represents file size in kb OR mb OR ... ]
> >>
> >>You can if you use OTP, but OTOH your "keys" would need to be the same
> >>size as your encrypted texts.
> >
> >Not at all. For example, I could encrypt 3 texts, of size 1k, 5k, and 10k,
> >and if the resultant cyphertext file was 30k, I'd have plenty of room to
> >hold them all. (Different bits of the cyphertext file code for the
> >different plaintexts).
>
> Explaining quite why a 1k plaintext encrypts to a 30k cyphertext
> might keep you busy.
------------------------------
From: "Stephen Fuld" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Wed, 12 Jul 2000 04:27:09 GMT
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Runu Knips wrote:
>
> > Mok-Kong Shen wrote:
> > > Runu Knips wrote:
> > > > And, well, Serpent contains a really complex initial (and final)
> > > > bit permutation, even if I don't understand whats the use for it,
> > > > except that the cipher is seriously slowed down in software.
> > >
> > > It seems to be the majority opinion that the IP and inverse IP of
> > > DES are entirely useless. Does anyone know any probable
> > > design rationale for that?
> >
> > Well, I already said this statement was <censored> !! ;-)
>
> Sorry, I don't understand the word 'censor' in this context. (I came
> to know what censorship means, when long ago I was living in a
> region occupied by foreign army in war.) I am the questioner in
> the question I formulated above and it is besides about DES, not
> Serpent. That same question I posed was also once raised in the
> group quite a time ago, but I don't remember that it ever got a
> good answer or even an half-good answer.
>
> M. K. Shen
>
>
The answer given before was correct. In the initial implementation of a DES
chip by IBM, the circuit designers requested it because it made the chip
simpler and would allow it for in the technology of the time. The
cryptologists (rightly) determined that it would not hurt the strength (nor,
as you pointed out, does it help), so they said OK. Remember, there was no
thought of the implications to software, because the request for proposals
by (then) NBS specifically required a hardware solution and expressly
disallowed a software solution.
--
- Stephen Fuld
>
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Wed, 12 Jul 2000 00:29:00 -0400
good one ...
Jim Howes wrote:
>
> John Winters wrote:
> >
> > Explaining quite why a 1k plaintext encrypts to a 30k cyphertext
> > might keep you busy.
> >
> > John
>
> No, it's explained easily. The user has written a 1k message
> using Microsoft Word
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Wed, 12 Jul 2000 00:40:39 -0400
current, well working stego have ration of 1 to 2 ...
and all are super safe / super stego ...
you are creating stego that will have ratio of 1 to 30 ...
what a waste of resources ...
phil hunt wrote:
>
> On Tue, 11 Jul 2000 16:15:38 +0100, Steve King <[EMAIL PROTECTED]> wrote:
> >John Winters wrote:
> >>
> >> In article <[EMAIL PROTECTED]>,
> >> phil hunt <[EMAIL PROTECTED]> wrote:
> >
> >> >
> >> >Not at all. For example, I could encrypt 3 texts, of size 1k, 5k, and 10k,
> >> >and if the resultant cyphertext file was 30k, I'd have plenty of room to
> >> >hold them all. (Different bits of the cyphertext file code for the
> >> >different plaintexts).
> >>
> >> Explaining quite why a 1k plaintext encrypts to a 30k cyphertext
> >> might keep you busy.
> >>
> >
> >Surely you would make sure that the one the FBI would see the 10k one, and
> >the relly secret one, that you were interested in was 1k.
>
> Indeed you might.
>
> >Not very efficient, but Top Secret stuff doesn't normally occupy a lot of
> >disk space.
>
> It's a trade-off. Encryption reduces efficiency, as you have to go to
> the trouble of decrypting, etc.
------------------------------
Date: Wed, 12 Jul 2000 00:54:29 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: OTP's again
sbh78 wrote:
> Ok, I have seen some commercial OTP products but they all talk about
> creating a large key file and transferring it to someone else so that they
> will be able to decrypt the messages sent to them. Here is my question
> can't the problem of key distribution for one time pads be solved by Diffie,
> Helman and Merkle's scheme. Think about the alphabet as a mod 26 system.
> Define a=1, b=2, c=3...z=26. Now, if we take 'd' and encrypt it with 'y'
> then our encrypted letter should be 'c' if we wrap around. Basically a
> ceasar shift of -1 right?? (I am relatively new to this so forgive me.)
> Anyway, lets say Alice encrypts a message with a OTP and sends her message
> to Bob who encrypts the message with an OTP and then sends that message back
> to Alice who decrypts with her OTP and sends it back to Bob who now decrypts
> it with his OTP to get the plain text. No keys were exchanged and the keys
> that were used were random and as long as the message. It could be done
> with all the ASCII characters so that any file could be encrypted. Would
> this work? Is it not implemented because it is impractical to do? Any
> thoughts?
Can you think of a way for someone with a copy of each of the messages you
described above to strip off the protection and reveal the plaintext? Hint: the
attacker needs only the first two messages in order to calculate the key to the
third message.
------------------------------
From: "sbh78" <[EMAIL PROTECTED]>
Subject: Re: Base Encryption: Strongest Cypher
Date: Tue, 11 Jul 2000 23:43:05 -0500
I have a question. Can you explain how it would be used practically? What
I mean is do you have to transmit a key to the person who will be decrypting
and how do you send that key. If you don't mind, just walk through how you
would send a message to me and then how I would decrypt that message.
Thanks in advance.
Wanting to Understand,
Stephen
--
****************************************************************************
******************
Stephen Haywood
273 E-I30 Apt. 205
Garland, TX 75043
[EMAIL PROTECTED]
****************************************************************************
******************
<[EMAIL PROTECTED]> wrote in message news:8kgr0j$p9t$[EMAIL PROTECTED]...
> The following describes the main features of Base Encryption.
> I will try to address legitimate points made by other in previous
> posts. For the rest, I suggest you seriously read the paper and
> understand it before making comments. Childish attacks covering
> up an inherent fear, or those that simply still don't get it,
> will simply be ignored (you know who you are). Read the previous
> Advanced Encryption FAQ if you are still having a difficult time
> sitting down and admitting the truth about Base Encryption.
> I have yet to find someone who can find a fault with Base Encryption.
> I have yet to find someone (maybe one, and I am addressing it here) who
> came close to making a scholarly comment on it.
> Is everyone here a reflection of the analytical abilities of the
> encryption community? I certainly hope not. I guess text-book
> trained minds can't think outside of the box. Come on, I challenge
> you: make a scholarly analysis of it with references. I have yet
> to find a post from someone who can really think, who can use their
> brains and not trapped behind a big ego.
>
> More info: http://www.edepot.com/phl.html
> 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)
>
>
>
> 1) Immune from plain-text-attacks.
>
> It is immune from plain-text-attacks because multiple algorithms
> can generate same plaintext. Multiple algorithms can generate
> same cyphertext. It is like saying how many ways are there to
> come up with 12345? (infinite: 12344+1, 12343+2, 1+1+1+12342, etc)
>
> 2) Immune from brute-force-attacks.
> It is immune from brute-force-attacks. A lot of pepple on this
> forum simply do not understand this. Read the Garage Door example,
> then the Chinese Newspaper, then come back to me. It is exponentially
> expensive. Then when you come back to me, and STILL don't get it.
>
> Get this...
> You don't know when you have the correct key. There is no way to
> find out. Because multiple algorithms can generate a text, you have
> no way to verify you have the correct key. So you can permutate the
> hard way, starting with 1 bit, then to 256 bits. Going through
> the values for EACH bit increase (rather than the current weak cypher's
> starting point at 256 bits (value 0) and end at 256 bits (value 256).
> Then after you permutate through all the keys, you have NOTHING!!!
> You don't know when you have found the answer. It is immune from
> brute-force-attacks on the basis the INABILITY for you test against
> the engine and know when you have the right key.
>
> 3) MORE secure as OTP.
> For those that still dont "get it". Here is a clue: Think of
> each piece of paper on the pad as a dynamic algorithm in Base
> Encryption.
>
> Now, you can use plain text attack on that piece of paper on the One
> Time Pad. Can you do that on Base Encryption? NO.
>
> 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.
>
> 5) Can utilize throwaway algorithms.
> Yes folks: As revolutionary as it sound!!
>
> 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.
>
> 8) Plug-And-Play engine (other cyphers can be augmentated to it)
> Yes, very modular.
>
> 9) Web-centric
> The engine need not reside on your client but diffused through
> the internet. Dynamic algorithms can be generated from dynamic
> content from websites.
>
>
>
>
>
> 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.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: OTP's again
Date: 12 Jul 2000 04:57:37 GMT
>Ok, I have seen some commercial OTP products but they all talk about
>creating a large key file and transferring it to someone else so that they
>will be able to decrypt the messages sent to them. Here is my question
>can't the problem of key distribution for one time pads be solved by Diffie,
>Helman and Merkle's scheme. Think about the alphabet as a mod 26 system.
>Define a=1, b=2, c=3...z=26. Now, if we take 'd' and encrypt it with 'y'
>then our encrypted letter should be 'c' if we wrap around. Basically a
>ceasar shift of -1 right?? (I am relatively new to this so forgive me.)
>Anyway, lets say Alice encrypts a message with a OTP and sends her message
>to Bob who encrypts the message with an OTP and then sends that message back
>to Alice who decrypts with her OTP and sends it back to Bob who now decrypts
>it with his OTP to get the plain text. No keys were exchanged and the keys
>that were used were random and as long as the message. It could be done
>with all the ASCII characters so that any file could be encrypted. Would
>this work? Is it not implemented because it is impractical to do? Any
>thoughts?
>
>Just Curious,
>Stephen
>
>
Lets look at this symbolically for one bit.
alice encrypts a
alice sends a^b to bob
bob sends a^b^c to alice
alice sends a^c to bob
bob decrypts a
This does not work for an insecure channel
To see why simply assume the opponent
sees all 3 messages.
and constructs
(a^b)^(a^b^c)^(a^c)=a
interception of the three messages breaks the
cipher.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Date: Wed, 12 Jul 2000 01:11:13 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: bank vault security (was Re: SecurID crypto (was "one time passwords
Eric Smith wrote:
> Roger Schlafly wrote:
> > You local bank probably thinks it has a secure vault, but
> > it still doesn't go out of its way to advertise the specs on it.
>
> "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> > Actually they do. The security of money entrusted to them is a
> > significant marketing issue. All those FDIC stickers serve the same
> > purpose. And if you inquire about the vault they'll tell you about
> > the vault (e.g., for safety deposit boxes), their security systems
> > etc.
>
> The bank is willing to tell you general things about the nature of the
> security, because they want you to believe it's secure so that they
> will get your business.
>
> Start asking them for fine details or blueprints, and you'll get a
> different response. They may be happy to tell you that they have an
> XYZco alarm system, and maybe even that it's a model 1234, but ask them
> for details of where all of the sensors are, or where the wires run.
> They won't give you that information because you don't have any
> legitimate need to know.
But vaults are designed to be secure even if I do have the blueprints. For
instance, a potential customer, or someone masquerading as such, could easily
show a need for an extremely detailed description. Any serious attack upon a
vault is going to be based on an intimate understand of the vault. The same
applies to an attack upon SecurID. The only thing secrecy does is preserve
our ignorance of exploitable weaknesses if there are any.
>
>
> The bank vault is designed to be strong even against knowledgeable
> attackers, but it *might* be even stronger against ignorant attackers, and
> it's not in the bank's best interest to educate the attackers.
> Obscurity can have *some* value, though only a fool would count on it
> primarily or exclusively.
Yes. But we usually do not consider software to be obscure. It's too easy to
copy and too easy to decode (as opposed to tracing circuits in an unknown
chip). And for systems that are widely used, obscurity does not exist.
>
>
> With crypto algorithms, it is generally advantageous to make the details
> public, because you want to encourage cryptanalysis *before* you deploy
> a gazillion instances of the algorithm. But the bank vault is (or at
> least can be) unique. Making the *exact* design of the vault available
> for public scrutiny is unlikely to turn up any vulnerabilities that
> aren't just as easily found with a model that is generally similar but
> different in the details. Whereas with crypto algorithms, those details
> can be critical to the security.
I think this comparison is apples v oranges. Consider the likely response to
a flaw in a vault -- the bank has to fix the flaw or add another layer of
protection over the vulnerability; replacing the vault is improbable.
Consider the likely response to a flaw in an algorithm -- it may be fixable,
but patching algorithmic flaws is probably a bad idea; better to replace the
system. Thus the revelation of a weakness in a vault is a lesser event than
the revelation of a weakness in an algorithm. Such a revelation does not
threaten the vendor's market.
Also, vaults don't tend to have weaknesses that can be exploited tracelessly.
Putatively secure software systems do.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Elliptic Curves encryption
Date: 12 Jul 2000 05:01:38 GMT
>Look at IEEE P1363 website for P13634a draft for ECIES method of encryption.
>Don Johnson
>
>
a web pointer for both would be appreciated.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
** 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
******************************
