Cryptography-Digest Digest #898, Volume #13 Wed, 14 Mar 01 17:13:00 EST
Contents:
Re: Instruction based encryption ("Simon Johnson")
Re: Instruction based encryption (David Wagner)
About one-time pad ("Haka")
Re: Digital enveloppe ("Ryan M. McConahy")
Re: About one-time pad ("Stephen Robert Norris")
Re: Digital enveloppe (br)
Re: About one-time pad ("Henrick Hellstr�m")
SSL secured servers and TEMPEST (Frank Gerlach)
Re: Crypto idea ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Instruction based encryption
Date: Wed, 14 Mar 2001 20:03:02 -0800
Michael Brown <[EMAIL PROTECTED]> wrote in message
news:EBlr6.915$[EMAIL PROTECTED]...
> Hi there,
>
> I brought up this topic a while ago, and never followed up on it much.
> Here's a description of the algorithm. I have implemented it in Delphi
(just
> tell me if you want the source), but I'm converting it to FreePas so that
> most people can use it (I know you guys don't like binaries!). A C port
> might come sometime this century (I hate C, but I'll do it if I'm forced
:)
>
> <=== BEGIN ALGORITHM ===>
>
> Each 128 bit key is made up of 16 "instructions", each of length 8 bits.
The
> instructions go from the most significant bit down to the least
significant
> bit. The first 3 bits of each instruction are the instruction, x, and the
> next 5 bits are the parameter n.
>
> Instruction table
> x
> 0 Xor with previous <n> plaintext bits
> 1 Xor with previous <n> ciphertext bits
> 2 Add previous <n> plaintext bits (under mod 256)
> 3 Add previous <n> ciphertext bits (under mod 256)
> 4 Subtract previous <n> plaintext bits (under mod 256)
> 5 Subtract previous <n> ciphertext bits (under mod 256)
> 6 Rotate left <n> bits
> 7 Rotate right <n> bits
>
> The initial "previous plaintext" and "previous ciphertext" are both just
> repetitions of the key.
>
> "Mash" key according to the following method:
> Xor key with previous 128 bits of plaintext
> Repeat 11 times: Key = Key XOR (Key ROR 11)
> (ROR = rotate right)
>
> This key mashing is done every 128 bytes.
>
> <=== BEGIN NOTES ===>
>
> The 128 byte key mashing is just a number I pulled out of the air, so
quite
> possibly is not enough or too often.
>
> The instruction table is quite possibly insecure, having both rotate left
> and rotate right.
>
> No key checking is done in the program. So you can get instructions like
> "xor with 0 previous plaintext bits"
>
> Using the key as the initial data might be insecure. A known plaintext
> attack would be most effective on the first 16 bytes of the file, as you
> could easily geerate the previous plaintext and ciphertext data. This
would
> still happen if you used a hash of the key though.
>
> If the key was extended to 256 bits, then the instruction table should be
> expanded to 16 instructions to avoid excessive repeats of instructions.
>
> This should implement very nicey in hardware I should think.
>
> <=== BEGIN SIGNATURE ===>
One way of doing such encryption (I have no idea if its secure or not) is to
have a Feistel structure where the f-function is just an s-box. Then what
you would do is generate 2^n s-boxes (where n is the length of your key in
bits) that all had identical properties, and the choice of s-boxes would be
the key. Clearly you wouldn't store all the s-boxes, what you would do is
find a set of function that made s-boxes all different but have identical
properties. I'm told the maths exists to do this but it generates boxes with
poor avalanche properties. Perhaps throwing a MDS at the end of the function
would help.
These are just ideas, I doubt that real security could be achieved this way.
Simon.
> ---
> Michael Brown
>
> Physics is no fun if you disregard friction.
>
>
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Instruction based encryption
Date: 14 Mar 2001 20:31:05 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Michael Brown wrote:
>How do you tell this? I actually tried to avoid linearness through inclusion
>of rotation and [...]
A rotation by a fixed (or key-dependent) amount is linear.
Rotations are non-linear only if the rotation amount is data-dependent.
------------------------------
From: "Haka" <[EMAIL PROTECTED]>
Subject: About one-time pad
Date: Wed, 14 Mar 2001 22:47:05 +0200
Hello, I don't know much about cryptology, but I came here searching for a
practical way for two cgi scripts to send safely small messages through the
internet (with perl).
I read all of the your excellent FAQ and I would like to ask you about this
simple solution to my problem i though of:
I read that the best way to encrypt a message is padding the entire message
with a key, which after use will be destroyed and never used again.
What I want is one cgi script to send a message to another about 100bytes
like http://www.server.com/host.cgi?encoded_message
where a part of the message would be some special bytes that tells the other
that this message was really sent from it.
So lets say I create a table about 16kb with random bytes. This table will
be shared between the scripts and completely private (and permanent). The
script would send a query like
/host.cgi?p=x&text=padded_encoded_message
where x the index in the table where the other script would start xor'ing
the encoded bytes back.
Now x would be a random number from 1 to 16kb. This way if each message is
about 100 bytes, the chances of sending a different message with the same
key (and thus revealing the authorization part of the message; some unique
bytes that tell the other script that the message is valid) whould be
1/16kb.
This is good enough for me, since about 10 messages like this would be sent
every day, and I could easily update the table like every month.
What do you think?
------------------------------
From: "Ryan M. McConahy" <[EMAIL PROTECTED]>
Subject: Re: Digital enveloppe
Date: Wed, 14 Mar 2001 16:07:57 -0500
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Have you no cryptographic knowledge? The security of the system must
not lie in the software, as yours would, or in the secrecy of the
algorithm, but in the security of the algorithm and the secrecy of
the password or private key.
A person can set the clock back. If it uses the recipients e-mail
address as the key, then the whole thing is insecure. There is no
need to use any stronger crypto than, say a Viginere cipher.
This program doesn't deserve to exist. PGP has been created. PGP is
open source. PGP uses public-key cryptography. PGP uses good
algorithms. PGP is a standard.
Go back to the drawing board and think up a new idea. If you want a
message to only be readable during a certan time period, you must
setup a special sever. The messages must be encrypted to that server
which would decrypt the message for you.
Have a good day,
Ryan M. McConahy
"br" apparently wrote in message <[EMAIL PROTECTED]>...
>I found a site using my idea but my idea doesn't need any Pin or
>password.
>http://www.digital-envelope.com/
>
>Only the recipient can open the email.
>
>Description of the system "digital enveloppe". I just quote it
>
>Digital Envelope is a simple but efficient way to encrypt all your
>emails so that nobody else than the
> recipient of the mail is able to read what you sent.
>
> The way it works:
>
> You encrypt your message with the recipients email
> address as
>key. You also can define how long the
> message will be readable by specifying an expiration
> period.
>If you have something really secret, you
> may enter an extra PIN or pass phrase. You must inform
> the
>recipient about this extra PIN, because
> otherwise s/he cannot read it. Then send your message.
>
> The recipient will get the encrypted message in the Inbox
> of
>the mail client. In order to decrypt it, a
> personal key must be requested here. The personal key is
>protected by a customer chosen Pin or pass
> phrase and is delivered by email to the email address
>specified in the key. Then the gets activated and
> the recipient can read your mail. So easy.
>
> We provide you with all the small pieces of software you
> will
>need for free, so visit our download pages.
>
> Some cryptographic details:
>
> The encryption uses a 128 symmetric encryption and in
>addition a chameleon type algorithm that
> changes its behavior during the encryption. We think, its
>pretty secure. Still there are more secure
> encryption schemes available, but this one will give you
> a
>good level of privacy.
>______________________________________
=====BEGIN PGP SIGNATURE=====
Version: 6.5.8ckt http://www.ipgpp.com/
Comment: KeyID: 0xA167F326A5BE3536
Comment: Fingerprint: 838C 815E 5147 2168 5A76 16F1 A167 F326 A5BE 3536
iQA/AwUBOq/dqqFn8yalvjU2EQJdEgCfbetnELFdeX5xvS5GO3b1ujoyTd4AnitZ
nH0aCm20S+Hs9+4Q/25wJTdK
=J7co
=====END PGP SIGNATURE=====
------------------------------
From: "Stephen Robert Norris" <[EMAIL PROTECTED]>
Subject: Re: About one-time pad
Date: Wed, 14 Mar 2001 21:21:14 GMT
In article <98olde$b0l$[EMAIL PROTECTED]>, "Haka" <[EMAIL PROTECTED]>
wrote:
> Hello, I don't know much about cryptology, but I came here searching for
> a practical way for two cgi scripts to send safely small messages
> through the internet (with perl). I read all of the your excellent FAQ
> and I would like to ask you about this simple solution to my problem i
> though of:
>
> I read that the best way to encrypt a message is padding the entire
> message with a key, which after use will be destroyed and never used
> again. What I want is one cgi script to send a message to another about
> 100bytes like http://www.server.com/host.cgi?encoded_message
>
> where a part of the message would be some special bytes that tells the
> other that this message was really sent from it.
>
> So lets say I create a table about 16kb with random bytes. This table
> will be shared between the scripts and completely private (and
> permanent). The script would send a query like
>
> /host.cgi?p=x&text=padded_encoded_message
>
> where x the index in the table where the other script would start
> xor'ing the encoded bytes back.
>
> Now x would be a random number from 1 to 16kb. This way if each message
> is about 100 bytes, the chances of sending a different message with the
> same key (and thus revealing the authorization part of the message; some
> unique bytes that tell the other script that the message is valid)
> whould be
> 1/16kb.
> This is good enough for me, since about 10 messages like this would be
> sent every day, and I could easily update the table like every month.
>
> What do you think?
Overlapping segments of the key would be bad! So, you can send 160
messages safely.
It would be better to do a standard MAC of some sort - at the simplest
level hash the message with a shared secret, and check the hash at the
other end.
Public key systems allow you to sign the data at one end without a shared
secret, which is generally more useful.
Stephen
------------------------------
From: br <[EMAIL PROTECTED]>
Subject: Re: Digital enveloppe
Date: Wed, 14 Mar 2001 16:27:13 -0400
I have no confidence on PGP or any other software.
Once, my idea of digital enveloppe achieved, I will disclose to everyone
the source. Everyone could compile it and use it.
If you feel safe using PGP, great.
Digital enveloppe is secure and easy to achieve.
I'm just trying to find better formula than that I had yet realized.
Thanks for your comment.
"Ryan M. McConahy" wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Have you no cryptographic knowledge? The security of the system must
> not lie in the software, as yours would, or in the secrecy of the
> algorithm, but in the security of the algorithm and the secrecy of
> the password or private key.
>
> A person can set the clock back. If it uses the recipients e-mail
> address as the key, then the whole thing is insecure. There is no
> need to use any stronger crypto than, say a Viginere cipher.
>
> This program doesn't deserve to exist. PGP has been created. PGP is
> open source. PGP uses public-key cryptography. PGP uses good
> algorithms. PGP is a standard.
>
> Go back to the drawing board and think up a new idea. If you want a
> message to only be readable during a certan time period, you must
> setup a special sever. The messages must be encrypted to that server
> which would decrypt the message for you.
>
> Have a good day,
>
> Ryan M. McConahy
>
> "br" apparently wrote in message <[EMAIL PROTECTED]>...
> >I found a site using my idea but my idea doesn't need any Pin or
> >password.
> >http://www.digital-envelope.com/
> >
> >Only the recipient can open the email.
> >
> >Description of the system "digital enveloppe". I just quote it
> >
> >Digital Envelope is a simple but efficient way to encrypt all your
> >emails so that nobody else than the
> > recipient of the mail is able to read what you sent.
> >
> > The way it works:
> >
> > You encrypt your message with the recipients email
> > address as
> >key. You also can define how long the
> > message will be readable by specifying an expiration
> > period.
> >If you have something really secret, you
> > may enter an extra PIN or pass phrase. You must inform
> > the
> >recipient about this extra PIN, because
> > otherwise s/he cannot read it. Then send your message.
> >
> > The recipient will get the encrypted message in the Inbox
> > of
> >the mail client. In order to decrypt it, a
> > personal key must be requested here. The personal key is
> >protected by a customer chosen Pin or pass
> > phrase and is delivered by email to the email address
> >specified in the key. Then the gets activated and
> > the recipient can read your mail. So easy.
> >
> > We provide you with all the small pieces of software you
> > will
> >need for free, so visit our download pages.
> >
> > Some cryptographic details:
> >
> > The encryption uses a 128 symmetric encryption and in
> >addition a chameleon type algorithm that
> > changes its behavior during the encryption. We think, its
> >pretty secure. Still there are more secure
> > encryption schemes available, but this one will give you
> > a
> >good level of privacy.
> >______________________________________
>
> -----BEGIN PGP SIGNATURE-----
> Version: 6.5.8ckt http://www.ipgpp.com/
> Comment: KeyID: 0xA167F326A5BE3536
> Comment: Fingerprint: 838C 815E 5147 2168 5A76 16F1 A167 F326 A5BE 3536
>
> iQA/AwUBOq/dqqFn8yalvjU2EQJdEgCfbetnELFdeX5xvS5GO3b1ujoyTd4AnitZ
> nH0aCm20S+Hs9+4Q/25wJTdK
> =J7co
> -----END PGP SIGNATURE-----
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: About one-time pad
Date: Wed, 14 Mar 2001 22:39:44 +0100
This has nothing to do with cryptology, but it ought to pointed out anyway.
What you suggest boils down to sending sensitive data using an HTTP
GET-command. That's usually either bad security - the cipher text will show
up in the history display of the browser - bad for performance - because the
cipher text has to be base64 encoded - or simply impossible because the
maximum length of the parameter part of a URL is not that great. Send it
using an HTTP POST-command instead.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"Haka" <[EMAIL PROTECTED]> skrev i meddelandet
news:98olde$b0l$[EMAIL PROTECTED]...
> Hello, I don't know much about cryptology, but I came here searching for a
> practical way for two cgi scripts to send safely small messages through
the
> internet (with perl).
> I read all of the your excellent FAQ and I would like to ask you about
this
> simple solution to my problem i though of:
>
> I read that the best way to encrypt a message is padding the entire
message
> with a key, which after use will be destroyed and never used again.
> What I want is one cgi script to send a message to another about 100bytes
> like http://www.server.com/host.cgi?encoded_message
>
> where a part of the message would be some special bytes that tells the
other
> that this message was really sent from it.
>
> So lets say I create a table about 16kb with random bytes. This table will
> be shared between the scripts and completely private (and permanent). The
> script would send a query like
>
> /host.cgi?p=x&text=padded_encoded_message
>
> where x the index in the table where the other script would start xor'ing
> the encoded bytes back.
>
> Now x would be a random number from 1 to 16kb. This way if each message is
> about 100 bytes, the chances of sending a different message with the same
> key (and thus revealing the authorization part of the message; some unique
> bytes that tell the other script that the message is valid) whould be
> 1/16kb.
> This is good enough for me, since about 10 messages like this would be
sent
> every day, and I could easily update the table like every month.
>
> What do you think?
>
>
>
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: SSL secured servers and TEMPEST
Date: Wed, 14 Mar 2001 23:38:24 +0100
I am not sure whether there is a better newsgroup for this, so please
tell me if you know such.
The problem is the following:
Some websites (like retail banks) have a lot of traffic, which is
secured with SSL. For each SSL session establishment (symmetric key
exchange), the secure RSA key must be processed either by the CPU (or
more likely) by a dedicated cryptographic coprocessor ("cryptobox").
Heavily used sites will have SSL session establishment rates in the
order of 100 per second. This means that the secret key is being
"broadcast" as often as the CRT signal of a PC. Admittedly, the signal
might be much weaker, but it is transmitted hundreds of thousands of
times over a couple of days. Also, it will *always*be the same signal,
contrary to a CRT signal.
Even if one encases the cryptographic processor in a lot of metal, there
must be a high-speed transmission link to the (web) server. To harden
the crypto processor, a fiber cable would be used for that purpose. As
power supply cables are always an emanation risk, the crypto processor
would be powered from an accumulator inside the metal casing.
Even with this kind of TEMPEST hardening, the signal will just be
dramatically attenuated, as there is the hole for the fiber and the
opening for the accumulator.
The attacker could record the emanations for days or even weeks on
broadband devices (essentially a farm of VCRs in a truck trailer) and
then let the "square acres of signal processors" do sophisticated
filtering on the recorded signal.
These are my questions:
-has anybody done some scientific considerations on this (maybe
estimatic attenuation & jamming needs for cryptographic processors) ?
-would salt water be a feasible strong attenuation medium (operating
the crypto device in a salt water barrel) ?
-are there any key usage policies *in use* to make this kind of
attack impossible (such as temporary certificates signed with the
"master" certificate of the site) ?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Crypto idea
Date: Wed, 14 Mar 2001 22:09:33 GMT
br <[EMAIL PROTECTED]> wrote:
: Using the brute force, it's impossible for any cryptanalist to read
: every output assuming the key x. But if you have the key it's then to
: read any message. Btu the cryptanalysis can't imagine that the output is
: "Ilov u " or Ay lovv u or etc...
: How the cryptanalist could imagine before trying to attack my
: cipher-text the way I had written I love you?
: How the cryptanalist could imagine before trying to attack my
: cipher-text the way I had create two types of characters that every
: human can distinguish? There an infinite way to create 2 types.
: Cryptanalisis is unarmed to attack my cipher.
: Cipher based on spelling mistakes and two categories is unattackable.
What if I wrote a program to interpret the text phonetically and compare
it against a phonetic dictionary. Presumably, ilovu and aylovvu might still
match "i love you", if you account for possibly pronouncing various letters.
That might permit a brute-force attack.
Mark
------------------------------
** 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
******************************
