Cryptography-Digest Digest #203, Volume #12 Tue, 11 Jul 00 13:13:01 EDT
Contents:
Free software (George Peters)
Re: Steganographic encryption system (Jim Howes)
Re: NTRU PKC (Roger Schlafly)
Re: SecurID crypto (was "one time passwords and RADIUS") (Roger Schlafly)
Re: One plaintext, multiple keys (David A Molnar)
Base Encryption FAQ (immune from plain-text attacks)) ([EMAIL PROTECTED])
Re: Proposal of some processor instructions for cryptographical (Benjamin Gamsa)
blowfish & 8 byte blocks (phil hunt)
Re: Concepts of STRONG encryption using variable base http://www.edepot.com/phl.html
(phil hunt)
Re: Who was that girl? (phil hunt)
Re: Steganographic encryption system (phil hunt)
Re: Steganographic encryption system (phil hunt)
Re: Steganographic encryption system (phil hunt)
Re: Steganographic encryption system (phil hunt)
Re: Missing nuclear secrets found behind Los Alamos copy machine (Doug Stell)
Re: IDEA CBC (Runu Knips)
Re: blowfish & 8 byte blocks (Mark Wooding)
Re: blowfish & 8 byte blocks (John Myre)
Re: Who was that girl? ("Theophilus Samuels")
Re: Proposal of some processor instructions for cryptographical (Paul Koning)
Re: Proposal of some processor instructions for cryptographical (Paul Koning)
----------------------------------------------------------------------------
From: George Peters <[EMAIL PROTECTED]>
Subject: Free software
Date: Tue, 11 Jul 2000 15:13:54 GMT
www.endecs.com/uenigma.exe. A full suite of encryption products in a
self-extracting .exe. Run setup after extraction (needs specialized
install).
Worth looking at.
------------------------------
From: Jim Howes <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Tue, 11 Jul 2000 15:55:15 +0100
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: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: NTRU PKC
Date: Tue, 11 Jul 2000 08:23:39 -0700
Vin McLellan wrote:
> In a sci.crypt post about SecurID crypto, I twitted Joseph Ashwood
> Mr. Ashwood, in reply, denied making those statements ...
You said that Ashwood trashed NTRU as a public key system, and
you said he said it was "shit", using quotes. The way I read
Ashwood, he was only attacking the application of NTRU to the
copy protection of music.
There's a big difference. NTRU may be a wonderful public key
cryptosystem, but no better than anything else for music copy
protection. Also, you shouldn't use quotes unless you are actually
quoting him.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: SecurID crypto (was "one time passwords and RADIUS")
Date: Tue, 11 Jul 2000 08:29:24 -0700
"Trevor L. Jackson, III" wrote:
> If you doubt that bureaucratic inertia and market forces lead to denial of insecurity
> consider the reaction of the French banking system to claims that their security was
> weak. They were furious about it, but denied it.
Have the French banks lost any money resulting from the small
size of their RSA modulus? If not, they perhaps the security
was strong enough for their purposes.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: One plaintext, multiple keys
Date: 11 Jul 2000 15:21:49 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> [snip]
> He was however asking for an example of block cipher, I suppose.
I know. I just wanted to give a somewhat natural example other than OTP.
I don't know of any natural examples for block ciphers, although it seems
you could come up with some explicitly stupid examples without too much
work.
-David
------------------------------
From: [EMAIL PROTECTED]
Subject: Base Encryption FAQ (immune from plain-text attacks))
Date: Tue, 11 Jul 2000 15:33:32 GMT
This Frequently Asked Questions (FAQ) provides information about
BASE ENCRYPTION. The strongest cypher in existence.
Why is Base Encryption strong?
Answer:
Base Encryption utilized many unique properties that are
unbreakable. It provides dynamic base (symbol set), dynamic
algorithms (operators and operations), and one-time-pad security
without the inconveniences. It is a full-fledged cypher that easily
fits into the internet's web-centric model.
Why is Base Encryption Strong?
Answer:
It is basically immune to brute-force attacks. You are not able
to permutate on a n+1 basis like static length keys. You do not
know the symbol set. You do not know the length. You do not
know the algorithms involved. You do not know anything! Even
if you know, you don't know if your "key" is correct! See below.
Why is Base Encryption Strong?
It utilizes the unique (I invented it first!) throw away
algorithms. Most encryptions these days can utilize throw-away
keys. But in Base Encryption, because the algorithms are
dynamic, in streaming cyphers or just plain normal encryptions
you can change algorithms on the fly based on arbitrary factors.
(time, length, etc).
Why is Base Encryption strong?
Answer:
In addition, base encryption is immune to plain-text-attacks.
Because multiple algorithms can generate a plain-text, plain
text attacks are useless against Base Encryption.
Why is Base Encryption Strong?
Answer:
Base Encryption is internet-ready, and modular. Because the
algorithm can be modified on the fly, you can use adaptive
plug-and-play cypher engines with it. Simply plug in twofish,
RC6, IDEA, as an augmentative step in the algorithm! Make one
up yourself and use it like another operator!
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.
------------------------------
Crossposted-To: comp.arch
From: [EMAIL PROTECTED] (Benjamin Gamsa)
Subject: Re: Proposal of some processor instructions for cryptographical
Date: 11 Jul 2000 14:36:24 GMT
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>Konrad Schwarz wrote:
>> From an abstract point of view, possibly. From a practical
>> point of view, I beleive not: the investment in byte addressable
>> hardware is just too large and the payoff of bit-addressing too small.
>
>Spoken like somebody who does not program communication protocols,
>error-correcting codes, etc.
>There is no fundamental obstacle. The main issue is that bit
>addresses require 3 more bits than octet addresses. Whoopdeedo.
But what should the size of the operation be (the number of bits read
and written)?
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: blowfish & 8 byte blocks
Date: Tue, 11 Jul 2000 14:30:14 +0100
Reply-To: [EMAIL PROTECTED]
My understanding is that Blowfish encrypts using 8 byte blocks. So
if my plaintext is just one byte long, encrypting it will produce an
8 byte ciphertext. When I decrypt this, will I get a 1 byte recovered
plaintext, or an 8 byte one? If an 8 byte one, how do I get back the
1 byte original?
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: Re: Concepts of STRONG encryption using variable base
http://www.edepot.com/phl.html
Date: Tue, 11 Jul 2000 14:32:05 +0100
Reply-To: [EMAIL PROTECTED]
On Tue, 11 Jul 2000 07:45:24 GMT, Bryan Olson <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> Tuche! (how do you spell that? Its the words you say
>> when you raise a sword at another person. And what
>> does it mean anyways?)
>
> ,
>It's spelled touche and it means "touch".
"touched", actually. Its the past participle of "toucher".
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: Re: Who was that girl?
Date: Tue, 11 Jul 2000 14:53:36 +0100
Reply-To: [EMAIL PROTECTED]
On Mon, 10 Jul 2000 23:44:58 -0400, An Metet <[EMAIL PROTECTED]> wrote:
>Please accept my apologies for this tyro question. I scanned the FAQ and
>didn't see any reference to this.
>
>About a year ago there was a news item in the popular press that a young
>girl (age 13-16) had created a rather sophisticated new cipher (I hope I
>have that right).
IIRC she was 16. This was about a year ago, so she's presuambly 17 now.
She's from Ireland; I don't recall her name.
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Tue, 11 Jul 2000 14:56:46 +0100
Reply-To: [EMAIL PROTECTED]
On Mon, 10 Jul 2000 19:39:36 +0100, Andrew McDonald <[EMAIL PROTECTED]> wrote:
>On Mon, 10 Jul 2000 18:07:37 +0100,
>phil hunt <[EMAIL PROTECTED]> 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.
>[snip description]
>>
>> I have some questions:
>>
>>
>> (1) does anything like this exist already?
>
>The thought that comes to my mind first is basing it on Rivest's
>Chaffing and Winnowing:
><http://theory.lcs.mit.edu/~rivest/chaffing.txt>
Having looked at this, it is similar to the algorithm I am using for stes.
>I'm fairly certain that people have done things with this (I think I
>might have seen something on Freshmeat <http://freshmeat.net/>).
I looked at FM too but didn't find anything (apart from what I've
described in my earlier posts on this thread).
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Steganographic encryption system
Date: Tue, 11 Jul 2000 15:06:16 +0100
Reply-To: [EMAIL PROTECTED]
On Mon, 10 Jul 2000 16:52:00 -0700, Joseph Ashwood <[EMAIL PROTECTED]> wrote:
>> If I have an encrypted file, and a key which purports to be a valid key
>> for my system, then surely anyone who knows the algorithm I'm using will
>> be able to easily find out whether the key is valid, by getting the data?
>> (Or are you saying that invalid keys should produce random-looking
>> data, but no indication that the key is bad?)
>
>If you use an All-or-Nothing-Tranform on the files, an attacker MUST go
>through attempting to get information from the entire file, in order to
>determine if the file contains information from that key (otherwise the data
>is difficult to distinguish from random), it's just another way to slow down
>the attacker. This also makes it more difficult for your application to leak
>information, but will make it more difficult to edit files, you'll be forced
>to remove then create them.
I think I get it now.
You're proposing an algorithm such that if as adversary has a ciphertext
and a possible key, then the adversary *can* find out whether the keys is
valid, *but* only by decrypting the whole ciphertext, which is likely to
take up a lot of CPU time, and thus hamper an adversary who is doing a
brute-force search on all possible keys.
Right?
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Tue, 11 Jul 2000 15:17:55 +0100
Reply-To: [EMAIL PROTECTED]
[message order normalised]
>> 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.
>"jungle" <[EMAIL PROTECTED]> wrote
>> what is the reason to decrypt into many different plaintext ?
On Tue, 11 Jul 2000 10:48:55 +0800, Chris Severn <[EMAIL PROTECTED]> wrote:
>I'd assume it's so that when the FBI comes knocking at your door demanding
>you give them the keys to your encrypted data, that you can do just that.
>You just give them the key that decrypts it to some non-sensitive
>information - not the good stuff.
>
>Sounds fair to me.
Got it in one. I imagine there's other benefits as well, but not having
a background in cryptography, I wouldn't know what they are.
?order wrong the in posts quote people some do why ,way the By
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Tue, 11 Jul 2000 15:42:45 +0100
Reply-To: [EMAIL PROTECTED]
On 11 Jul 2000 06:46:48 +0100, John Winters <[EMAIL PROTECTED]> 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.
Not at all. If you try to encrypt a 1K file, the system will *always*
produce a ciphertext which is substantially larger. This has the advantage
of helping to defeat traffic analysis attacks.
Since stes will be open source, it probably won't be too difficult to prove
to a court that this is the case.
--
***** Phil Hunt ***** send email to [EMAIL PROTECTED] *****
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Crossposted-To: alt.war.nuclear
Subject: Re: Missing nuclear secrets found behind Los Alamos copy machine
Date: Tue, 11 Jul 2000 15:54:26 GMT
>> ]That encryption is not of sufficient strength to protect data as
>> ]sensitive as this. I would posit that any encryption scheme that
>> ]is simple enough that a set-top box can decode it in real time, albeit
>> ]with a known decoding algorithm; is insufficiently secure to stand
>> ]up to a cryto-analytic attack of any great length of time.
>>
>> That statement is false. A set-top box has enough computing power to
>> implement an algorithm like Skipjack or Blowfish, which have been
>> extensively attacked by the best cryptographers.
>
>Michael,
>
> Do you know if Skipjack and/or Blowfish encryption is approved to
>safeguard classified data of the Secret Restricted Data variety?
Blowfish isn't approved for protecting anything of interest to the
Government. It is a commercial or Type 3 algorithm. As such, it is
ignored by the Government.
SKIPJACK is a Type 2 algorithm and can protect only Unclassified But
Sensitive (SBU) data. There is very little data that falls into this
category. It can be used to provide a second layer of protection for
data that is normally protected by a stronger mechanism. It has been
temporarily approved for use in protecting classified data, but I
believe that that approval has expired.
Only Type 1 algorithms are approved to protect classified (SECRET and
TOP SECRET) data. These high-grade algorithms are all classified and
provided by the NSA.
The statement about set-top boxes is false. We do Type 1 algorithms in
telephone handsets, modem-like boxes that are the size of DiskMan, and
on other small platforms. The AIM chip can be programmed to do a bunch
of them. They are strong and some of them are fast. SKIPJACK is a dog
and there is one Type 1 algorithm that is an order of magnitude
faster.
------------------------------
Date: Tue, 11 Jul 2000 18:19:28 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: IDEA CBC
Sam Simpson wrote:
>
> --
> Sam Simpson
> Comms Analyst
> http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
> Delphi Crypto Components. PGP Keys available at the same site.
>
> Runu Knips <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Daouda Timera wrote:
> > > I won to get information about the difference beetwen the
> idea_cbc40 and
> > > the idea_cbc56 and how can I implement it ( to generate the
> necessary
> > > 128 Bits Key vor encryption) vor WAP (WTLS -Layer)
> >
> > Sounds like DES with 40 or 56 bit keys, both in CBC mode.
>
> Wasn't the use of the word "idea" a hint? ;)
You're right :-) I've didn't read the posting too carefully. Sorry
I'm really tired today... and when I read 'cbc' I automagically
added 'DES' for that was the algorithm for which CBC was defined
in the beginning ...
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: blowfish & 8 byte blocks
Date: 11 Jul 2000 16:40:14 GMT
phil hunt <[EMAIL PROTECTED]> wrote:
> My understanding is that Blowfish encrypts using 8 byte blocks. So
> if my plaintext is just one byte long, encrypting it will produce an
> 8 byte ciphertext. When I decrypt this, will I get a 1 byte recovered
> plaintext, or an 8 byte one? If an 8 byte one, how do I get back the
> 1 byte original?
Blowfish transforms 8-byte blocks to 8-byte blocks. If you want to
encrypt shorter blocks, you have to put some information in them so that
you know how to truncate again afterwards. One possibility is to add
between 1 and 8 padding bytes to the text, until it's a multiple of 8
bytes long, each byte being the number of padding bytes you added.
Or you could use CFB mode, which doesn't produce larger ciphertexts if
you do the buffering properly.
-- [mdw]
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: blowfish & 8 byte blocks
Date: Tue, 11 Jul 2000 10:52:55 -0600
phil hunt wrote:
>
> My understanding is that Blowfish encrypts using 8 byte blocks. So
> if my plaintext is just one byte long, encrypting it will produce an
> 8 byte ciphertext. When I decrypt this, will I get a 1 byte recovered
> plaintext, or an 8 byte one? If an 8 byte one, how do I get back the
> 1 byte original?
Actually, Blowfish (along with most other block ciphers) cannot
encrypt a one byte plaintext at all. You have to add seven bytes
yourself, *then* give the block to Blowfish to encrypt. If you
decrypt the resulting eight bytes, you will get back the original
eight bytes: your one byte plaintext and the seven bytes you added.
So if you want your original plaintext, you have to remove your
own padding.
JM
P.S.
More on the subject: investigate "padding schemes" and "block
cipher modes".
------------------------------
From: "Theophilus Samuels" <[EMAIL PROTECTED]>
Subject: Re: Who was that girl?
Date: Tue, 11 Jul 2000 18:03:09 +0100
Ironically, the successful attack on the Cayley-Purser algorithm is carried
out using the Cayley-Hamilton conjecture.
T.L.S.
An Metet <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Please accept my apologies for this tyro question. I scanned the FAQ and
> didn't see any reference to this.
>
> About a year ago there was a news item in the popular press that a young
> girl (age 13-16) had created a rather sophisticated new cipher (I hope I
> have that right). I've not seen anything on the subject since then, and I
> would very much like to follow up on it.
>
> If someone could direct me to a good URL that discusses this, I would be
> most appreciative. I recall reading the list of research topics undertaken
> by the young people that won (whatever prize it was), and it too was most
> impressive. A link to those topics would be very helpful too.
>
> Probably this is old news to you regulars in here, but I'm still learning.
> Thanks in advance for any guidance anyone can give me.
>
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Tue, 11 Jul 2000 12:45:05 -0400
"Douglas A. Gwyn" wrote:
>
> Konrad Schwarz wrote:
> > From an abstract point of view, possibly. From a practical
> > point of view, I beleive not: the investment in byte addressable
> > hardware is just too large and the payoff of bit-addressing too small.
>
> Spoken like somebody who does not program communication protocols,
> error-correcting codes, etc.
I do all that and I agree with Konrad...
> There is no fundamental obstacle. The main issue is that bit
> addresses require 3 more bits than octet addresses. Whoopdeedo.
No, the bigger issue is that bit addressing requires 8 times as
many write enable lines on the bus.
The reason byte access works efficiently is that system buses have
byte lane enables so you can selective byte writes *without* the
absurd overhead of a read/modify/write sequence. To do that on a
bit basis requires bit write enables. And you'd need memory that
has per-bit write enables, which is fine if you have Nx1 memory
chips but not if you have Nx4 or Nx8 as happens often enough.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Tue, 11 Jul 2000 12:52:47 -0400
"Douglas A. Gwyn" wrote:
>
> Jayant Shukla wrote:
> > The AES candidates are not too _tiny_. In fact, the fully pipelined
> > version of the AES candidates could not be fitted on Xilinx XC4000
> > FPGA. The NSA paper shows that even the most efficient implementation
> > of these algorithms in hardware takes up > 23 mm^2 of silicon.
> > Don't even ask about the fully pipelined versions ( ~1000 mm^2).
>
> Sounds to me like somebody screwed up. The TMS320C6201 versions
> were something like 1KB each on average.
That's a software implementation; its size tells you essentially
nothing about the gate count of a hardware implementation.
You can go read the paper, though I'm not sure it has enough
detail to let you second-guess the authors. I'm not qualified
to do that, but what I read didn't sound out of line to me.
Note that fully pipelined implementations are only useful in
specialized applications, because they gain you nothing in CBC
encrypt mode. Also, a real implementation would not be an
FPGA. Nevertheless, comparisons like the one NSA did are very
helpful in demonstrating the *relative* complexity of hardware
implementations of the various candidates.
paul
------------------------------
** 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
******************************
