Cryptography-Digest Digest #885, Volume #13 Tue, 13 Mar 01 15:13:01 EST
Contents:
Re: OverWrite: best wipe software? ("Tom St Denis")
Re: Crypto idea (David Schwartz)
on-the-fly encryption ("%NAME%")
Re: GPS and cryptography (br)
Re: GPS and cryptography (Bill Unruh)
Re: Quantum Computing & Key Sizes (Bill Unruh)
Re: Meaninog of Kasumi (Mike Rosing)
Re: GPS and cryptography ("Trevor L. Jackson, III")
Re: GPS and cryptography ("Trevor L. Jackson, III")
Re: Instruction based encryption (David Finch)
Re: Text of Applied Cryptography .. do not feed the trolls ("Trevor L. Jackson, III")
Re: Crypto idea ("Trevor L. Jackson, III")
Re: Cheap hardware to break RSA? (Mike Rosing)
Re: GPS and cryptography (David Schwartz)
Re: Really simple stream cipher ("Henrick Hellstr�m")
Re: Really simple stream cipher ("Henrick Hellstr�m")
Re: Exportable key lengs & Mush algorithm (Frank Gerlach)
----------------------------------------------------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Tue, 13 Mar 2001 18:10:06 GMT
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Benjamin Goldberg wrote:
> >
> > You claim to have demonstrated a "procedure whereby the OverWrite
> >
> >
> > ><snip>
> >
> >
> > The difference between theory and practice is that in theory, theory and
> > practice are identical, but in practice, they are not.
>
>
> Let me ask you then, using OverWrite and my procedure of a dedicated
> hard drive partition, etc., why will not the desired file be
> thoroughly overwritten? Give us just one objection and we will
> pursue it like a pack of dogs pursues the fox.
Well I can say it's inconvenient to partition my drive to use your tools. I
will lose all my data!
Tom
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Crypto idea
Date: Tue, 13 Mar 2001 10:04:02 -0800
br wrote:
> I'm aware that it's impossible to use this system for commercial
> purposes. But for military or intelligence use, it's appropriate.
Why use techniques that are hard to implement when there are techniques
that are simple to implement that can provide whatever degree of
security you wish? But the biggest flaw in your scheme is that it is
heavily reliant upon human beings. Experience shows that they are the
weakest link in most chains.
This has three problems:
1) It relies upon a trick. If the trick gets out, the encryption is
compromised.
2) Human beings would have to know what the trick was. And so they
could tell someone or be coerced.
3) The trick can't be regularly changed, because it is one of a fixed
number of such tricks.
Surely if you were designing a military encryption scheme, you'd prefer
one that didn't rely upon a trick that could be compromised. And you
certainly would prefer one where human beings never ordinarily know the
actual key secret (and so can't compromise it).
DS
------------------------------
From: "%NAME%" <[EMAIL PROTECTED]>
Subject: on-the-fly encryption
Date: Tue, 13 Mar 2001 12:54:27 -0500
Hi encryption experts,
I apologize in advance if this message appears twice, because I tried
posting this once already and it didn't seem to work.
I am a newcomer to cryptography, and I have a question about on-the-fly
encryption. Many software programs claim to provide on-the-fly
encryption services, where encryption/decryption of a file is done
automatically when a file is accessed.
I have a question regarding this concept:
1) When a file is accessed and on-the-fly encryption is used, where is
this file stored while I'm using the file? In memory somewhere? What
if the file is large? The file must be decrypted during use, but it
cannot be stored in the hard disk, or that would defeat the purpose of
on-the-fly encryption.
Any reponses will be greatly appreciated.
Thank you,
Betty
------------------------------
From: br <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Tue, 13 Mar 2001 13:32:55 -0400
The recipient own the GPS and is in position that allow him to read the
message.
It's very simple.
How could you know all technical features of my GPS?
The software include some data about technical features of the
recipient.
Whithout those data and the real position no one can read the message.
It's not hard to design the system.
Try to imagine that every computer is unique.
Try to find a relation between this unicity and the key to decipher the
message.
GPS is just a component of the system.
You can use the phone of the recipient as key (not the phone number).
Than means that every computer is described by stable technical
parameters.
So the computer X cand read only messages sent to it.
If you don't own the computer X with its hardware components, it's
impossible to read any message.
How to communicate all parameters?
Via network.
I have invented unbreakable system to communicate safely via network.
I'm going to publish it this groupnews.
I'm trying to write it in english. A french version is still not
complete.
I'm french speaking.
Tom St Denis wrote:
>
> "br" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> > How could you know the data before faking?
>
> How does the legitimate receipient know?
>
> Tom
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: GPS and cryptography
Date: 13 Mar 2001 18:43:00 GMT
In <[EMAIL PROTECTED]> br <[EMAIL PROTECTED]> writes:
]It's impossible.
No it's not. Depends on how much effort you want to expend, but you can
go from feeding your GPS receiver fake data, to faking the output of the
reciever,
]Tom St Denis wrote:
]>
]> "br" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
]> > What do you think about using Global Positionning System (GPS) as key to
]> > encryption?
]> > You can read a message only if your computer is a pre-defined area or
]> > point in the earth.
]> > I'm waiting for comments
]>
]> What if I fake my position?
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Quantum Computing & Key Sizes
Date: 13 Mar 2001 18:46:52 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (DJohn37050)
writes:
>IBM has built a 7-bit QC, when many people said a 3-bit QC could never be
>built. And there are more ideas to try to take it farther, but who knows how
>far it can go.
Well, not IBM, and the problem with QC is that they do not scale. Ie at
present adding each bit is as hard as adding the last bit. The current
QC Moore's law is one bit per year. Since to factor a 1000 bit number
will probably take of the order of 1000000 bits, it could be a while.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Meaninog of Kasumi
Date: Tue, 13 Mar 2001 12:54:20 -0600
Gregory G Rose wrote:
> "Kasumi" means "fog", and the name is derived (as
> is the algorithm) from MISTY.
Thanks, that makes sense.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Tue, 13 Mar 2001 18:59:20 GMT
br wrote:
> I have invented unbreakable system to communicate safely via network.
We'll reserve judgment on that.
>
> I'm going to publish it this groupnews.
Good. (groupnews --> newsgroup)
>
> I'm trying to write it in english.
Take your time. Get it right.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Tue, 13 Mar 2001 19:01:22 GMT
br wrote:
> My idea is that GPS as device is connected to the computer. It's
> hardware encryption.
> If you have a position x then you can read the message which is
> encrypted whith any cryptosystem E(k). If you are in other location you
> can't read the message even if you know the key K.
Explaining bits and pieces won't work. You need to provide a complete
description of the system or you will not be treated seriously.
------------------------------
From: David Finch <[EMAIL PROTECTED]>
Subject: Re: Instruction based encryption
Date: Tue, 13 Mar 2001 11:03:00 -0800
Reply-To: [EMAIL PROTECTED]
Your key mashing has a serious flaw. I expect your key to become 0 after 128
xor's. You should see your plaintext in your ciphertext or your plaintext xor'd
with itself shifted 1 bit after the first 1.5k, depending on how whether your
instructions accept 0-31 or 1-32 for n. Either way it looks pretty bad.
You lose one bit of information each time you rotate and xor something with
itself.
Example of problem with rotating and xoring:
starting with a random 8bit number:
10011101
I will rotate 1 bit and xor it with itself several times.
10011101
11001110
01010011
10101001
11111010
01111101
10000111
11000011
01000100
00100010
01100110
00110011
01010101
10101010
11111111
11111111
00000000
after 8 rotations and xors, you are left with 0
Each remaining rotate and xor will result in 0.
You should always ensure that your "mashing" function is 1 to 1. You can add
constants, you can do an unsigned shift (not a rotation) and xor that with it.
You can permutate the bits in any way. You can multiply it by an odd number. You
can encrypt it (but not using itself as a key). But you shouldn't do anything
that can't always be undone, because it means you may lose bits, and the key may
even get stuck at a constant like 0.
Michael Brown wrote:
> 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 ===>
>
> ---
> Michael Brown
>
> Physics is no fun if you disregard friction.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: Tue, 13 Mar 2001 19:04:19 GMT
Paul Schlyter wrote:
> In article <[EMAIL PROTECTED]>,
> Paul Rubin <[EMAIL PROTECTED]> wrote:
>
> > [EMAIL PROTECTED] (Paul Schlyter) writes:
> >> In particular since paper can be resued too! Books, newspapers, etc
> >> which are thrown away can be recycled into paper used for printing
> >> new books/papers.
> >
> > Yes, and paper recycling uses a lot of energy, plus creates a lot of
> > incredibly nasty pollution.
> >
> > Bits good, paper bad.
>
> Unfortunately you cannot read bits directly -- you must somehow
> store, transport and display them. All that requires energy -- and
> the energy to produce and run your personal computer isn't all -- you
> must also include the energy to run the infrastructure (e.g. the
> Internet) you're using.
>
> New trees grow by themselves -- new copper, plastic and glass doesn't....
<nit>Actually copper does. It is one of the few metals (with lead, gold,
etc.) that occur in the elemental/metallic state in nature (on this planet).
</nit>
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Crypto idea
Date: Tue, 13 Mar 2001 19:08:14 GMT
br wrote:
> Some ideas to discuss
>
> The computer is idiot. If it is not programmed for any pre-defined
> task, it can't distinguish between uggly and beautiful lady, english
> and foreign alphabets etc...
> So if I use two categories of symbols, which one has a property
> different than the other, the computer can't know that the message
> include two types differents.
> I'm going to give you some samples.
> Let plain text in binary system : 001101
> Suppose that I want to send a message whithout send a key to my
> correspondant.
> I send 249583. Every one understand that odd number is replaced by 1 and
> even by 0.
> It's very easy to guess.
> If I use open letters like l,u,r,s ... and closed letters like o, p, b,
> d, e. It's more difficult. It's impossible for cryptanalysts to find out
> the output when I know that creating two categories is infinite domain.
>
> Cryptanalysis use dictionaries as way to find a solution. They suppose
> that the clear message is wrote without spelling mistakes.
> I can write a message like "I love you" as " Ay lov u" or "Ilovu"etc....
> So how cryptanalists could know before my specific spelling of I love
> you.
>
> Using spelling mistakes is a good strategy against attackers.
> Using "symbolic characters" with two differents properties too.
> So what if I use spelling mistakes combined with symbolic characters
> before encryption.
> 1.I convert "I love you" to " Ay lov u".
> 2.Then Ay lov u to (It's just an example) 101101....11
> 3. 101101... to +a-*c=...<>
> 4. Everyone can guess that I used mathemathical symbols for 1 and
> litteral symbols for 0.
> (the receiver has to program using two types and inserting in table the
> characters corresponding to one or zero and try to read twice to know
> symbols (one) et symbols (zero).
>
> I'm aware that it's impossible to use this system for commercial
> purposes. But for military or intelligence use, it's appropriate.
>
> I apologize for my english, I hope it was clear.
You are mixing steganography (hiding messages) with cryptography (scrambling
messages). The crypto has to be strong in case the stego fails.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Cheap hardware to break RSA?
Date: Tue, 13 Mar 2001 13:18:45 -0600
Sven Gohlke wrote:
> Why don�t You use analog computer to do this job? They are both, cheap and
> fast so it seems to me, that they are a perfect choice.
Because you need accuracy. An analog computer is accurate to 4 places at
the most. To make it accurate to 1000 bits of precision is impossible.
Patience, persistence, truth,
Dr. mike
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Tue, 13 Mar 2001 11:21:19 -0800
br wrote:
>
> The recipient own the GPS and is in position that allow him to read the
> message.
> It's very simple.
> How could you know all technical features of my GPS?
> The software include some data about technical features of the
> recipient.
> Whithout those data and the real position no one can read the message.
> It's not hard to design the system.
> Try to imagine that every computer is unique.
> Try to find a relation between this unicity and the key to decipher the
> message.
> GPS is just a component of the system.
> You can use the phone of the recipient as key (not the phone number).
> Than means that every computer is described by stable technical
> parameters.
> So the computer X cand read only messages sent to it.
> If you don't own the computer X with its hardware components, it's
> impossible to read any message.
> How to communicate all parameters?
> Via network.
> I have invented unbreakable system to communicate safely via network.
> I'm going to publish it this groupnews.
> I'm trying to write it in english. A french version is still not
> complete.
> I'm french speaking.
If you have to send all the information about your computer over the
network to allow people to encode messages to you, haven't you just
given out the key to your message?
Let me put it another way. Your computer's behavior is either
predictable or unpredictable given the information you give the sender.
If your computer is predictable based upon the information you give the
sender, then an attacker can simulate your computer and break the
message. If your computer's behavior cannot be predicted by the encoder
based upon the data you sent, then how can he encode the message such
that it doesn't decode to garbage?
It's not clear how GPS is supposed to figure into this. If the person
encoding the message doesn't know the technical details of your GPS, how
can he use them to encode the message? If he does know them, then
couldn't an attacker know them by the same means? If not, how is the
"technical features of the recipient" different from just a random
secret key?
What would you would need (but don't even claim to have) is some
mechanism to give out sufficient information to encode a message to a
particular recipient but not enough information to decode that same
message. If you had this, you would have reinvented public-key
cryptography with a fixed key. Since we already have such schemes
(several of them) with changeable keys, all you would accomplish would
be to remove a feature from existing PK schemes.
How about this, I make a box (call it a 'smartcard') that has a private
RSA key stored securely inside it. The public key is printed on the back
of the card. If I want you to be able to send me an encrypted message, I
simply tell you the techical parameters of my smartcard (ie, the public
key). You can now send me a message that only someone with my computer
(err, smartcard) can decrypt.
DS
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Tue, 13 Mar 2001 20:31:57 +0100
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:98lmln$dvj$[EMAIL PROTECTED]...
> Henrick Hellstr�m wrote:
> >If a MAC is present it must be recognized as such by the crypto software.
>
> Why is this a risk? The crypto layer sets the crypto format.
>
> And, if you get it wrong for some reason, the worst that happens is that
> everything stops working, and then you know you need to fix something.
> In other words, the system is fail-safe, rather than becoming insecure
> when it fails.
You might have such expectations if you know that the server and client uses
identical crypto software, yes, but that wasn't what I described.
It's certainly not fail safe to encrypt something with one crypto software
and decrypt it with another. If you do this, there are two different crypto
layers possibly setting two slightly different formats, because there might
be compatibility issues not covered by any official documentation or
standard simply because noone thought about them. You cannot take for
granted that everything will stop working if anything goes wrong under such
circumstances. No software developer is able to anticipate every single
decision made by every other software developer.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Really simple stream cipher
Date: Tue, 13 Mar 2001 20:45:05 +0100
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:98lmi7$dvj$[EMAIL PROTECTED]...
> Again, you're comparing PCFB to CBC+HMAC, while I'm comparing explicit
> to implicit authentication. The two issues should not be conflated, as
> you yourself have pointed out: PCFB can be used with either implicit or
> explicit authentication. If you're going to use PCFB, the performance
> of using it in an implicit mode is about the same as for an explicit mode,
> I claim.
Sure, if you mean that using it in "explicit mode" is the same as calling
any kind of crypto library function returning True for success and False for
failure. All it would take to comply with this definition of explicit mode
would be to lift some code out of one (application) function and place it in
another (crypto library).
One possible problem might be that the redundancy check might take quadratic
time if it had to be generalized (haven't thought much about how the
algorithm would look), while it might be done in linear time or even
constant time in an application specific routine. Besides that, I see no
reason to disagree.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Exportable key lengs & Mush algorithm
Date: Tue, 13 Mar 2001 21:56:43 +0100
Randy Langer wrote:
> Two questions for the group:
>
> 1) What is tha actual key length restriction for export now? I've heard
> every possible stoty on this now (40 bits, 56, 128, unlimited), and no
> compelling reason to believe one over the others. Our application is
> embedded crypto with no public crypto API (ie., our product is not a gen
> purpose crypto product like PGP), used in OEM cores for dev by 3rd
> parties (including extraterritorial) for mass-market consumer products.
Hand it over to NSA and let them rig it a little bit. The bureaucratic
processes will then be much more simple :-)
Seriously, this is how it was in the bad old days. Now they only do it in a
time of international crisis :-)
------------------------------
** 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
******************************
