Cryptography-Digest Digest #145, Volume #14 Sat, 14 Apr 01 23:13:00 EDT
Contents:
Re: MS OSs "swap" file: total breach of computer security. (Steve Portly)
Re: LFSR Security (John Savard)
Re: Function other than xor? (John Savard)
Re: Patents for Enigma ?? (John Savard)
Re: LFSR Security (Nathan E. Banks <[EMAIL PROTECTED]>)
Re: Function other than xor? (newbie)
Re: LFSR Security (David Wagner)
Re: Concerning US.A.4979832 (John Savard)
Re: NSA is funding stegano detection ([EMAIL PROTECTED])
Announcing A New Rijndael Encryption Algorithm Implementation (bloopa)
Re: LFSR Security ("Trevor L. Jackson, III")
Re: LFSR Security (Tim Tyler)
----------------------------------------------------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: Sat, 14 Apr 2001 20:58:35 -0400
Anthony Stephen Szopa wrote:
> AY wrote:
> >
> > >MS is intentionally placing our right
> > >to privacy at risk.
> >
> > There are easier ways for MS to invate the user's privacy than deliberately
> > implementing a insecure swap file system. In any case I think better
> > programming _could_ help with the swap file security issues.
> >
> > >The only discretion one has at this time is to NOT use any leaky MS
> > >security sieve of an OS.
> >
> > Hmm....
> > > X-Mailer: Mozilla 4.7 [en] (Win98; I)
>
> I just made a post regarding my XOR_TextBox software (many
> expressed grave concerns about it) addressing this very issue.
>
> You must first know the function before you need to know the
> implementation of a swap file procedure.
>
> If you have sufficient RAM then the swap file, apparently, is not
> utilized.
>
> You may want to take a quick look at that post.
If you declare your plain text variable as a single byte sized global variable
and encrypt one byte at a time you alleviate several risks. The global variable
is overlaid each time you are encrypting a new plain text byte. Not only do you
not get large streams of plain text in your swap file, memory sniffer programs
running concurrently will not be able to access the global variable until the
program terminates.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Sun, 15 Apr 2001 01:43:07 GMT
On Sat, 14 Apr 2001 15:17:47 -0500, Nathan E. Banks <Paganini>
<[EMAIL PROTECTED]> wrote, in part:
>Hmm. In a private email someone told me that XORing multiple LFSRs would
>help a lot, especially if they were of different sizes. Could someone
>explain why one or the other is true? :)
For technical reasons, the XOR of several LFSRs is essentially
equivalent to a single LFSR with the sum of their sizes - provided
those sizes are different. The math is fairly complicated.
But there are other ways to combine the output of LFSRs; if you use a
method that is nonlinear (technically, neither linear nor affine) you
may be able to achieve some degree of security. My web page, although
it doesn't attempt to explain the advanced math of LFSRs, does give
examples of some constructs that have tended to be considered as
possibly secure.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Function other than xor?
Date: Sun, 15 Apr 2001 01:55:04 GMT
On Sat, 14 Apr 2001 17:49:58 -0300, newbie <[EMAIL PROTECTED]>
wrote, in part:
>> Hi mathematicians
>> Is there a function that create logical relation between to bit-string?
>> without using any table.
>> DES is f(010001...) = 010100101..... the size is 64.
>> I'm looking for a general bijective function
>> Whatever is the size of the block. I'm mean globally not related bit by
>> bit.
>> Not the inverse f -1, not a permutation function.
>> Sample: f(0100101001) = 0101001010
>> or f(010) = 011
>> Has someone created this kind of function?
>> Thank you for help.
and then:
>The title is wrong.
>Only function because Xor is operation.
>Excuse me.
As far as I know, no one has created a block cipher that operates on
blocks of arbitrary size in bits.
Certainly, there are many unkeyed functions that can be applied to bit
strings of arbitrary size. Most, though, are trivial.
For example, f(bit-string) could be that string with every bit
inverted, the string with its bits in reverse order. But you've
specifically included anything that trivial.
On the other hand, what about the function on n-bit strings of the
number in that string, multiplied by some odd number, modulo 2^n? That
would meet your criteria of involving every bit, and being bijective.
Do it twice, reversing the order of the bits in between.
That would meet the criteria you've set, but I think you're looking
for something of higher quality, something like a block cipher.
One could devise a block cipher that works, say, for blocks of any
length in bits starting at a minimum size of 16 bits or 32 bits or 40
bits or so, but I don't think one could devise one that scales well
all the way down to blocks of one, or even three, bits in size.
Rijndael is designed to scale to blocks whose length is any multiple
of 32 bits, starting with 128 bits. I think I could fairly easily
design a block cipher that wouldn't be too horribly insecure that
worked, say, on blocks of any multiple of 8 bits, or even 4 bits,
starting with 32 bits or so, but getting much more flexible than that
would be difficult.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Patents for Enigma ??
Date: Sun, 15 Apr 2001 01:57:46 GMT
On Sat, 14 Apr 2001 15:23:26 GMT, [EMAIL PROTECTED] (Lawrence
Kirby) wrote, in part:
>However the context was Britain's use of "the Typex rotor machine"
>so are we talking about commercial or spook use?
Although that issue was mentioned later in the thread, the initial
post simply argued that, since the Enigma machine was patented,
'getting a patent means zero'. Full stop. (translation: Period.) In
general, for any invention, or at least any cryptographic invention,
so I understood that to mean for any and all markets.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Nathan E. Banks <Paganini> <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Sat, 14 Apr 2001 20:59:59 -0500
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> "Nathan E. Banks " wrote:
> It has nothing to do with higher math, but everything to do with the insecurity
> of linear systems. The Ell in LFSR stands for linear. This means that LFSR
> systems are not secure. Adding them together does not reduce the linearity, so
> it does not reduce the weakness.
Isn't linearity a requirement for decryption? I mean, the keystream has
to be able to be duplicated on the recieving end in order for the
ciphertext to be decrypted. In something like this doesn't nonlinearity
imply real randomness?
-- Paganini
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: Function other than xor?
Date: Sat, 14 Apr 2001 22:05:32 -0300
John Savard wrote:
> As far as I know, no one has created a block cipher that operates on
> blocks of arbitrary size in bits.
>
> Certainly, there are many unkeyed functions that can be applied to bit
> strings of arbitrary size. Most, though, are trivial.
Thank for your answer. But, I want just to know wich functions.
Some samples will help me.
I want function simple, logic, and easy to use.
It means that you can revert by simple computing the function without
the help of any kind of table.
DES is a keyed-function with block-size 64.
>
> For example, f(bit-string) could be that string with every bit
> inverted, the string with its bits in reverse order. But you've
> specifically included anything that trivial.
I talked about inversion, permutation or modulo. So, is there another
way other than those functions?
>
> On the other hand, what about the function on n-bit strings of the
> number in that string, multiplied by some odd number, modulo 2^n? That
> would meet your criteria of involving every bit, and being bijective.
> Do it twice, reversing the order of the bits in between.
>
> That would meet the criteria you've set, but I think you're looking
> for something of higher quality, something like a block cipher.
I just want to know if those functions exist.
Because I'm working on what I hope is a new idea. New function with a
lot of implications.
I'm newbie. I discovered crypto just 6 months ago.
I'm reading some articles and the useful book of Menendez.
I'm very grateful.
Thank you.
> One could devise a block cipher that works, say, for blocks of any
> length in bits starting at a minimum size of 16 bits or 32 bits or 40
> bits or so, but I don't think one could devise one that scales well
> all the way down to blocks of one, or even three, bits in size.
>
> Rijndael is designed to scale to blocks whose length is any multiple
> of 32 bits, starting with 128 bits. I think I could fairly easily
> design a block cipher that wouldn't be too horribly insecure that
> worked, say, on blocks of any multiple of 8 bits, or even 4 bits,
> starting with 32 bits or so, but getting much more flexible than that
> would be difficult.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: 15 Apr 2001 02:16:09 GMT
Nathan E. Banks wrote:
>Isn't linearity a requirement for decryption?
No. In a secure system, the keystream should be a nonlinear
function of the key. (Often the ciphertext is a linear function
of the keystream and the plaintext, and that's not a problem.
What *is* a problem is when the keystream is linear in the key.)
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Concerning US.A.4979832
Date: Sun, 15 Apr 2001 02:25:16 GMT
On Sat, 14 Apr 2001 21:15:17 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>Again, I am aware of no prior art which anticipates the invention.
I don't think there's any prior art which anticipates the preferred
embodiment.
"Algorithm M", noted as a reference (but not specifically cited among
the examples of relevant prior art) appears to be an example of the
more general class of Dynamic Substitution operations claimed in the
patent.
Since this algorithm, however, was previously used only as a specific
algorithm, and not as part of a general class of methods - and it was
not formerly thought of as a 'substitution', although technically it
_could_ be seen that way, I don't think that this limits the
applicability of your patent to any other form of Dynamic
Substitution. Only the use of Algorithm M itself, and perhaps some
minor variations directly derived from it (i.e., two-layer
MacLaren-Marsaglia) would likely be exempt from your patent. One
example of this principle would be the Schnorr patent in public-key
cryptography, where a general family of Diffie-Hellman-based signature
algorithms was patented, but which included a few cases which were
previously known - and patented.
However, if you were going to also include substitutions which change
without a table holding the substitution being directly involved - for
example, key feedback mode of DES - then I would have to say that I
think rotor machines, for example (as patented by Edward S. Hebern),
would be an example of prior art. A changing substitution, applied to
the plaintext letter, is produced from the rotor displacements, so the
rotors combine the gear movements with the plaintext letter.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: Sun, 15 Apr 2001 02:43:08 GMT
I'd have thought that detection of otherwise well constructed
steganography would be based on statistical analysis of the degree of
entropy or randomness in the data. Any unencrypted image, or other
file, intended to convey information is by definition not random. So
GIFs, JPEGs etc are not random. It would be perfectly feasible to
analyze a huge quantity of such files (ones without hidden messages)
to establish their statistical properties - in particular the degree
of randomness. Then one could focus on statistical comparisons of
files being sent by others with a view to establishing whether there
is any probability that the degree of randomness is more or less than
expected. Thus routinely embedding a pseudo-random (encrypted) file
in an image must marginally bias the degree of randomness of values in
the data. But, if the message is very small in proportion to the
container, then probability of detection is reduced. And, if very few
messages are sent, then probability of detection is also reduced.
On this basis, I suspect that those using steganography in pictures
should:
1) use messages that are small relative to the container
2) send images containing messages infrequently
3) send lots of images which contain no messages
4) perhaps, consider ways to salt encrypted messages after encryption
such that the frequency of bit values is not random, but rather
reflects the distribution of bits in the original container image, so
as to leave the statistical properties of bit values in the container
unvaried once the image is embedded.
One wonders if anyone has already written a crypto/steganographic
program that does 4?
In any case, one supposes that someone will have done the work to
analyse the degree of randomness in images without hidden files versus
thos with under a variety of schemes. This would provide hard data on
the relative risks, and so, the effects of the ratio of message size
to container size in terms of detectability.
It may be that based on such analysis, the attacker would require an
infeasibly huge sample of messages before being able to detect any
statistically significant difference. The choice of the level
statistical significance would be the attackers of course. In this
exercise it is the ratio of the innocent who are hauled in for
questioning (or whatever) as opposed to the guilty. A p=0.05 level
would mean 1 in every 20 suspects would probably be innocent. I
suspect that in many regimes they might be perfectly content with
p=0.95 in which 19 out of twenty suspects are innocent. If so, this
means that anyone sending messages is likely to be questioned, sooner
or later, no matter how sophisticated their encryption/steganography,
in which case one needs to consider other approaches which are not to
do with crypto/steganography, such as doing business in (with?) a less
oppressive regime.
NB The above is intended as a contribution to an abstract discussion.
If the original poster in this thread is making decisions which may
affect the life chances of those who may use crypto/steganography,
then he should NOT rely on posts such as this, as it is NOT an
adequate basis for such decisions.
On Sun, 15 Apr 2001 01:44:16 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
>
>Niels Provos wrote:
>>
>
>> Essentially, you trade off hiding capacity against security.
>> The more data you hide, the easier it will become to detect
>> distortions in the statiscial properties of an image. If
>> your pseudo-random selection considers only LSB values, you
>> neglect statistical properties that depend on the whole value,
>> e.g. coefficient frequency in JPG.
>[snip]
>
>But aren't the statistical properties of an image
>dependent on the image? There is no 'standard' of such
>properties, isn't it? Now the opponent doesn't
>have the original image. He has no idea of the 'correct'
>statistical properties. How does he know that the
>modified statisitical properties aren't really
>the genuine ones?
>
>Another question, between modifying the LSB of the pixels
>and modifying the LSB of DCT coefficients, which approach
>is better, why?
>
>Thanks in advance.
>
>M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (bloopa)
Subject: Announcing A New Rijndael Encryption Algorithm Implementation
Date: Sun, 15 Apr 2001 03:06:15 GMT
VSpace Encrypted Chat
Note: This version of VSpace Encrypted Chat is a complimentary release and as
such only provides 32-bit encryption. This version is free from use
restrictions. Please contact [EMAIL PROTECTED] for information on how to
obtain a 256-bit encryption release.
http://www.vspacecorp.com/vschat2.zip
Warning
This program is not intended for use outside of the United States or by
private individuals. Severe penalties will be assessed if you are investigated
and found to be in possession of this Cipher System. Only approved
Corporations and Government Agencies may use VSpace Encrypted Chat.
VSpace Encrypted Chat is a secure communications platform that was designed to
protect sensitive conversations from intelligence gathering. VSpace defines
intelligence gathering as data mining by:
� Hostile Governments
� Foreign Armed Services
� Foreign Nationals
� Hostile Religious Organizations
� Corporate Spies
� Industrial Espionage
� Russian and Ukrainian Mafia
� International and Domestic Terrorists
� Former Employees
� Internet Hackers
The threat to your security is very real. Simply inspect your firewall records
to convince yourself.
What makes VSpace Encrypted Chat so secure?
Under the United States Federal Regulations concerning domestic encryption,
all cipher systems intended for public use must be inspected and approved by a
government agency. These systems must also have a documented back door so that
law enforcement will be able to break the cipher.
These rules do not apply for private corporations and government agencies.
VSpace Encrypted Chat does not contain any back doors. This freedom from
restrictions also allowed us to develop and insert into VSpace Encrypted Chat
a unique implementation of the Rijndael Encryption Algorithm that defeat all
known attacks.
VSpace Rijndael Implementations
Rijndael
The default encryption algorithm that VSpace Encrypted Chat uses is straight
Rijndael. This is where you supply a password at the beginning of your session
and all sentences are encrypted with the same key that was generated from that
password for the duration of the session.
This method is very secure; especially when using 256 bit keys which is also
the default. However, VSpace doesn�t like to anything normally. They set out
to make it even stronger, if it were possible.
Rijndael Plus
This is VSpace�s proprietary implementation of the Rijndael algorithm that
completely renders harmless all known attacks. This is where you supply a
password at the beginning of the session and from that point on every letter
that you type is treated as its own document and is encrypted with its own
unique password that was spawned from the original. If your sentence contains
50 characters including spaces and periods, Rijndael Plus will produce 50
separately encrypted documents that were made from 50 separate passwords!
Just trying to crack �Mary had a little lamb� this way would use more
resources than the value of the data received. Imagine how difficult it would
be to determine exactly where to look into a conversation between three or
more individuals for the intelligence that you are seeking? Especially when
the printed cipher text may be 10mb or larger?
If you were to guess correctly the password, it would do you no good without
knowing exactly what to do with that password now that you have it. The
original password is never used to generate keys. It is used to spawn other
passwords that will generate keys.
The Encrypting Rijndael Algorithm - AES
Rijndael algorithm
The Rijndael algorithm, also known as an Advanced Encryption Standard (AES),
is used for encryption and decryption of files and text.
Rijndael is an iterated block cipher with a variable block length and a
variable key length. The
block length and the key length can be independently specified to 128, 192 or
256 bits.
The Advanced Encryption Standard (AES) will be a new Federal Information
Processing Standard (FIPS) Publication that will specify a cryptographic
algorithm for use by U.S. Government organizations to protect sensitive
(unclassified) information. NIST also anticipates that the AES will be widely
used on a voluntary basis by organizations, institutions, and individuals
outside of the U.S. Government - and outside of the United States - in some
cases. NIST has selected Rijndael as the proposed AES algorithm.
You can learn more about the Rijndael algorithm and AES at:
� http://csrc.nist.gov/encryption/aes/
� http://www.nist.gov/public_affairs/releases/g00-176.htm
Why did NIST select Rijndael to propose for the AES?
When considered together, Rijndael's combination of security, performance,
efficiency, ease of implementation and flexibility make it an appropriate
selection for the AES. Specifically, Rijndael appears to consistently perform
well in both hardware and software across a wide range of computing
environments regardless of its use in feedback or non-feedback modes. Its key
setup time is excellent, and its key agility is good. Rijndael's very low
memory requirements make it very well suited for restricted-space
environments, in which it also demonstrates excellent performance. Rijndael's
operations are among the easiest to defend against power and timing attacks.
Additionally, it appears that some defense can be provided against such
attacks without significantly impacting Rijndael's performance. Rijndael is
designed with some flexibility in terms of block and key sizes, and the
algorithm can accommodate alterations in the number of rounds, although these
features would require further study and are not being considered at this
time. Finally, Rijndael's internal round structure appears to have good
potential to benefit from instruction-level parallelism.
AES key sizes
The AES will specify three key sizes: 128, 192 and 256 bits. In decimal terms,
this means that there are approximately:
3.4 x (10^38) possible 128-bit keys;
6.2 x (10^57) possible 192-bit keys; and
1.1 x (10 ^77) possible 256-bit keys.
What is the chance that someone could crack an AES key?
Assuming that one could build a machine that could recover 255 keys per
second, then it would take that machine approximately 149 thousand-billion
(149 trillion) years to crack a 128-bit AES key. To put that into perspective,
the universe is believed to be less than 20 billion years old.
What about the other four algorithms that were not selected?
In terms of security, NIST states in its report that "all five algorithms
appear to have adequate security for the AES." NIST is not saying that there
is anything "wrong" with any of the other four algorithms. However, when all
of the analysis and comments were taken into consideration, the NIST team felt
that Rijndael was the best selection for the AES.
Adequate security, conformed by NIST, is the reason why VSpace Encrypted Chat
implements the Rijndael algorithm for its encryption.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Sun, 15 Apr 2001 03:08:04 GMT
David Wagner wrote:
> Trevor L. Jackson, III wrote:
> >As soon as you have 2N bits regularly sampled you can solve for the initial
> >state.
>
> Even when the taps are unknown and part of the key? If so, how?
Regular sampling transforms the LFSR to an alternate characteristic function.
If you use BM to find that function there's a reverse transform (that I would
have to go find) to recover the original characteristic function.
------------------------------
Crossposted-To: sci.crypt.random-numbers
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: LFSR Security
Reply-To: [EMAIL PROTECTED]
Date: Sun, 15 Apr 2001 02:59:34 GMT
: David Wagner <[EMAIL PROTECTED]> wrote:
:> Trevor L. Jackson, III wrote:
:> >As soon as you have 2N bits regularly sampled you can solve for the
:> >initial state.
:>
:> Even when the taps are unknown and part of the key? If so, how?
:
: Simple: the output of an length N LFSR, sampled once every M outputs, is
: identical to the output of another length N LFSR with possibly different
: taps. So, all you need to do is run the BM algorithm on the virtual LFSR.
: If you want to, you can translate the results back to the original LFSR.
There are some problem cases that might prevent the data from throwing
light on the initial state of the original LFSR - namely if M is a
factor of the period of the N-bit LFSR.
--
__________
|im |yler Try my latest game - it rockz - http://rockz.co.uk/
------------------------------
** 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
******************************
