Involutional ciphers

[Richie Frame]

Anubis and Khazad are ciphers using an involutional structure and components, however their key schedule prevents the entire cipher from being a full involution.

Inspired by a stack exchange post, I threw together 2 ciphers that are full involutions. Obviously the applications of such a cipher are limited. I am curious if anyone has done any work with something similar, or has explored the security implications regarding key recovery or distinguishers.

Making a cipher that is a full involution essentially makes it a keyed 1:1 nonlinear mapping between 2 states. Should it even be called a cipher?

I used AES to build it as it is fast, convenient, easy to test intermediate states, and with minimal development time.




FIAESTY is a full involution block cipher using a Feistel structure with palindromic round keys. It has 27 rounds and a 256-bit block size. It uses the AES round as the F-function, allowing reuse of bulk AES implementation code as well as AESNI instructions.

The key schedule is identical to AES except for the production of 1 extra round key, which limits the key size to 128/192/256-bits.


Basic overview of structure and round key application:

With A and B as the left and right half of the state, R is the round function referencing a subkey, and S is the state swap:

R(i) =
A = A xor MixColumns(ShiftRows(SubBytes(B))) xor subkey(i)
Whitening(i,j) =
A = A xor subkey(i)
B = B xor subkey(j)


Whitening(00,01)

R(02) S R(03) S
R(04) S R(05) S
R(06) S R(07) S
R(08) S R(09) S
R(10) S R(11) S
R(12) S R(13) S
R(14) S R(15) S
R(14) S R(13) S
R(12) S R(11) S
R(10) S R(09) S
R(08) S R(07) S
R(06) S R(05) S
R(04) S R(03) S
R(02)

Whitening(00,01)




SHIAESTY is identical to FIAESTY except for the key schedule, which uses SHA-512 iteratively, extracting a 128-bit round key in between. An arbitrary length key is hashed, the first 128-bits of output are extracted, and the entire 512-bit output is used as the input to the next hash iteration, this is repeated till all round keys are generated. Advantages are that a single round key cannot be used to derive information about the other round keys, higher nonlinearity than the AES KS, reuse of SHA-512 code and/or modules, and computationally expensive key changes. Computational expense is also a disadvantage if the use environment requires key agility.

[austin...@hotmail.com]

My recent posting of "shuttlePads" can legitimately be claimed to be an instance of an involution cipher - Perhaps you could check this sometime - adacrypt

[austin...@hotmail.com]

On Saturday, May 16, 2015 at 10:50:41 AM UTC+1, Richie Frame wrote:

Apologies - should have given more info =>

Alice encrypts plaintext to get Bob's ciphertext.

Using the very same function Bob can encrypt Alice's ciphertext to get back to her Plaintext.

f(P) = C
F^-1() = P

Bob's decryption is the inverse of Alices encryption function ? - adacrypt

[Richard Heathfield]

On 19/05/15 17:31, austin...@hotmail.com wrote:

<snip>

>
> My recent posting of "shuttlePads" can legitimately be claimed
> to be an instance of an involution cipher - Perhaps you could
> check this sometime

I'd be glad to.

ShuttlePads works (roughly) like this:

Step 1: substitute each character in the plaintext with a different
character, using a randomly generated S-box (or "pad", as you call it),
where the S-box is secret. J becomes P, P becomes L, L becomes +, or
whatever it is.
Step 2: having completed all the substitutions, skip X characters, then
divide all except the last Y characters into K groups, each W characters
wide, and rotate each group around the midpoint. So if W is 5, ABCDE
would become EDCBA. If W is 4, ABCD would become DCBA. X, W, K, and Y
are secret.

For this to be an involution cipher, decryption would proceed as follows:
Step 1: substitute each character in the plaintext with a different
character, using a randomly generated S-box (or "pad", as you call it),
where the S-box is secret. J becomes P, P becomes L, L becomes +, or
whatever it is.
Step 2: having completed all the substitutions, skip X characters, then
divide all except the last Y characters into K groups, each W characters
wide, and rotate each group around the midpoint. So if W is 5, ABCDE
would become EDCBA. If W is 4, ABCD would become DCBA. X, W, K, and Y
are secret.

If you actually do this, however, the plaintext is not recovered. To
recover the plaintext, you have to do the reversal first, not second,
and you have to run the "pads" backwards - + becomes L, L becomes P, P
becomes J, etc.

Conclusion: ShuttlePads is not an involution cipher.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[austin...@hotmail.com]

You weren't asked - why don't you shut up - adacrypt

[y]

Richard Heathfield He still think his ShittlePads is secire?

-y

[Richard Heathfield]

On 19/05/15 20:51, austin...@hotmail.com wrote:
> On Tuesday, May 19, 2015 at 7:56:49 PM UTC+1, Richard Heathfield wrote:
>> On 19/05/15 17:31, austin...@hotmail.com wrote:
>>
>> <snip>
>>
>> >
>> > My recent posting of "shuttlePads" can legitimately be claimed
>> > to be an instance of an involution cipher - Perhaps you could
>> > check this sometime
>>
>>
>> I'd be glad to.
>>
>> ShuttlePads works (roughly) like this:

<snip>

>> Conclusion: ShuttlePads is not an involution cipher.
>

> You weren't asked - why don't you shut up

By posting to the sci.crypt newsgroup, you invited comment from
subscribers to the sci.crypt newsgroup, of whom I am one. If you want to
have private conversations, use email.

If you think I am *mistaken* in claiming that ShuttlePads is not an
involution cipher, you have a perfect opportunity here and now to
explain why you think I am mistaken.

But I'm not, because it isn't. It really, truly isn't.

If ShuttlePads consisted *only* of the rotation phase, it would indeed
be an involution cipher, albeit a trivially weak one.

Allow me to demonstrate:

Plaintext: ABCDEFGHIJKLMNOPQRSTUVWXYZ
X = 2 (skip first two letters)
K = 3 (number of groups)
W = 7 (width of each group)
Y = 3 (width of final unspun group)

Process: Skip 2, rotate 3 lots of 7 letters, don't touch last 3

Groups look like this:

AB CDEFGHI JKLMNOP QRSTUVW XYZ

Rotate:

AB IHGFEDC PONMLKJ WVUTSRQ XYZ

So that's your ciphertext. To decrypt, perform exactly the same step
again. Groups look like this:

AB IHGFEDC PONMLKJ WVUTSRQ XYZ

Rotate:

AB CDEFGHI JKLMNOP QRSTUVW XYZ

and there we are - the original plaintext is recovered.

But ShuttlePads consists of two steps, not one. You have to undo the
second step before you undo the first step. So you're not using the same
process to decrypt as you are to encrypt. Encryption consists of STEP1
STEP2, but decryption consists of STEP2 INVERSEOFSTEP1

The different ordering, and the fact that Step 1 must be inverted, both
constitute differences between encryption and decryption. So you don't
have an involution cipher.

Here are very some examples of involution ciphers:

void bitflip(unsigned char *p, size_t len)
{
while(len--)
{
*p = ~*p;
++p;
}
}

void onetimepad(unsigned char *p, unsigned char *k, size_t len)
{
while(len--)
{
*p++ ^= *k++;
}
}

In each case, the process for decryption is precisely the same as for
encryption:

unsigned char buffer[] = { 65, 66, 67, 68, 69 };
unsigned char key[] = { 59, 81, 93, 44, 82 };

bitflip(buffer, sizeof buffer); /* encrypt */
bitflip(buffer, sizeof buffer); /* decrypt */

onetimepad(buffer, key, sizeof buffer); /* encrypt */
onetimepad(buffer, key, sizeof buffer); /* decrypt */

That's what it means to be an involution cipher. ShuttlePads does not
qualify.

[David Eather]

He can't learn or understand ANYTHING, so of course he thinks it is secure.

[MM]

On Tuesday, 19 May 2015 17:31:37 UTC+1, austin...@hotmail.com wrote:
> My recent posting of "shuttlePads" can legitimately be claimed to be an instance
> of an involution cipher - Perhaps you could check this sometime - adacrypt

Having the source may make things easier. Here it is:

https://www.dropbox.com/s/132z9il0be3zty4/ShuttlePads.zip?dl=0

Its truly horrible, and may take some time to comprehend due to the author's inability
to express himself properly.

Folks who like amusing examples of bad code may enjoy this!

M
--

[MM]

On Tuesday, 19 May 2015 20:51:51 UTC+1, austin...@hotmail.com wrote:
> You weren't asked - why don't you shut up - adacrypt

You told me you weren't going to post on sci.crypt again, you liar!

M
--

[Richard Heathfield]

On 19/05/15 22:59, MM wrote:
> On Tuesday, 19 May 2015 17:31:37 UTC+1, austin...@hotmail.com wrote:
>> My recent posting of "shuttlePads" can legitimately be claimed to be an instance
>> of an involution cipher - Perhaps you could check this sometime - adacrypt
>
> Having the source may make things easier. Here it is:
>
> https://www.dropbox.com/s/132z9il0be3zty4/ShuttlePads.zip?dl=0

247 files(!)

Deleting the .exe and .o files still leaves 188.

Is this some kind of esoteric joke? The source code should aid
understanding, not hinder it!

[Richard Heathfield]

To be fair, it's quite common for people to say that they are
withdrawing from a newsgroup, only to change their minds later. It's a
bit harsh to call such people liars.

On the other hand, it /is/ fair to regard such claims as... uh... unwise.

In mid-2010 I decided that Usenet was taking up too much of my time, so
I stopped using it. But I wasn't so silly as to announce the fact. I
just stopped posting for a few years.

The ensuing reports of my death were somewhat exaggerated. :-)

[MM]

On Tuesday, 19 May 2015 23:20:55 UTC+1, Richard Heathfield wrote:
> On 19/05/15 23:01, MM wrote:
> > On Tuesday, 19 May 2015 20:51:51 UTC+1, austin...@hotmail.com wrote:
> >> You weren't asked - why don't you shut up - adacrypt
> >
> > You told me you weren't going to post on sci.crypt again, you liar!
>
> To be fair, it's quite common for people to say that they are
> withdrawing from a newsgroup, only to change their minds later. It's a
> bit harsh to call such people liars.

Not this time. I will post the communications involved if there is an attempt to
deny.

--

[MM]

On Tuesday, 19 May 2015 23:13:43 UTC+1, Richard Heathfield wrote:
> 247 files(!)
>
> Deleting the .exe and .o files still leaves 188.
>
> Is this some kind of esoteric joke? The source code should aid
> understanding, not hinder it!

I did my best (offline) to help him. He wasn't interested.

M

[Rich]

Richard Heathfield <r...@cpax.org.uk> wrote:
> On 19/05/15 22:59, MM wrote:
> > On Tuesday, 19 May 2015 17:31:37 UTC+1, austin...@hotmail.com wrote:
> >> My recent posting of "shuttlePads" can legitimately be claimed to be an instance
> >> of an involution cipher - Perhaps you could check this sometime - adacrypt
> >
> > Having the source may make things easier. Here it is:
> >
> > https://www.dropbox.com/s/132z9il0be3zty4/ShuttlePads.zip?dl=0

> 247 files(!)

> Deleting the .exe and .o files still leaves 188.

> Is this some kind of esoteric joke? The source code should aid
> understanding, not hinder it!

Egads this is some horribly written code.

One also would need to remove the "self made version control" files,
i.e.,:

Shuffle_n_Slice.adb
Shuffle_n_Slice.adb.0
Shuffle_n_Slice.adb.1
Shuffle_n_Slice.adb.2
Shuffle_n_Slice.adb.3

since apparently he also has never heard of version control programs.

Moving out of the way all the *.[0-9], *.ads, *.ali, *.c and *.dat
files still leaves 33 files. Quote a good obsfucation job on his part.

This also explains why he operates under the mis-belief that each of
his pads requires 'extrememly complicated programming' to generate.
He's got ten 4kb source files, one for each of his ten pads. About
40kbyte for what is just creating a 'randomized' lookup-table.

Each of the 4k 'pad' sources also explains why he can't internalize
that his 'pad' is nothing more than an S-box. He sees his 4k of code
per pad as 'not an s-box' because it is separate 4k chunks of code to
generate each, so they 'can't be as simple as an s-box' in his mind.

[red floyd]

On 5/20/2015 4:22 AM, Rich wrote:

>
> Moving out of the way all the *.[0-9], *.ads, *.ali, *.c and *.dat
> files still leaves 33 files. Quote a good obsfucation job on his part.
>

OT, but the ADS files are needed. Those are the package specs. They're
roughly (but not completely) equivalent to C header files.

[Rich]

Ah, good to know. Moving them back makes for 51 files.

This also helps to explain why he never presented his algorithm when
pressed. This obfuscation is such that he likely has no acutal
understanding or idea just what the underlying algorithm of his cipher
actually is, therefore he never posted it because he could not
articulate it.

[MM]

On Wednesday, 20 May 2015 18:01:23 UTC+1, Rich wrote:
> This also helps to explain why he never presented his algorithm when
> pressed. This obfuscation is such that he likely has no acutal
> understanding or idea just what the underlying algorithm of his cipher
> actually is, therefore he never posted it because he could not
> articulate it.

Accurate.

Wait till you see this construct (pseudocode):

for i := 1 .. 10 do
if i = 1 then
do_first_cycle
end if
if i = 2 then
do_second_cycle
end if
if i = 3 then
do_third_cycle
end if
// same for all 10 cycles
end for

... where all the do_nth_cycle are near-identical and not all that small, and
lend themselves well to parameterisation.

He prefers it that way because that is the way he thinks, apparently.

Changing the loop iterations from 10 to something else would take "a few
days". Apparently that is not a problem.

--

[Richard Heathfield]

On 20/05/15 22:36, MM wrote:

<re AOB's ShuttlePads implementation in Ada>

> Changing the loop iterations from 10 to something else would take "a few
> days". Apparently that is not a problem.

For comparison, my C implementation (posted in this group fairly
recently) consists of four files:

lcprng.h (13 lines)
lcprng.c (35 lines)
keygen.c (61 lines)
shuttlepads.c (367 lines)

Total: 476 lines.

The key generator requires the two lcprng files and keygen.c. Number of
lines requiring modification to change the number of "pads": 1

The ShuttlePads program itself requires the two lcprng files and
keygen.c. Number of lines requiring modification to change the number of
"pads": 1

This is twice as much work as it should be: I should factor out the
change into shuttlepads.h, as I could then reduce the number of lines to
be changed to 1. Better still, I could make it a command-line argument,
reducing the number of lines to be changed to 0.

Either of these improvements could be coded in, at worst, ten minutes.

Of course, my implementation is not guaranteed to be a faithful
implementation of ShuttlePads, because we *still* don't have a clear,
unambiguous description of the algorithm.

[Rich]

Just looked that up in the files. I'm nearly speechless. I've seen
copy-n-paste code before, but this takes it to a whole new level of
copy-n-paste programming. Ouch....

[y]

Sorry for him, this software has a lot of work ( writing it, not thinking ),
is not a failure becouse the sources compiled.
this code has the beauty of the internal wiring of the enigma machine (a famous german encryption machine that has 6 ShuttleRings). and i'm 100% sure that has his great level of security too.

-y

[Richard Heathfield]

On 21/05/15 01:11, y wrote:

<snip>

> Sorry for him, this software has a lot of work ( writing it, not thinking ),

If he is still of school age (which seems unlikely), then yes, I feel a
little bit sorry for him. But if he's a grown-up, he should have learned
by now that his coding style is inherently inefficient and needs to change.

> is not a failure becouse the sources compiled.

That's an interesting perspective. :-)

> this code has the beauty of the internal wiring of the enigma machine

No, it doesn't.

> (a famous german encryption machine that has 6 ShuttleRings). and i'm
> 100% sure that has his great level of security too.

The Enigma (which the Allies did manage to crack, of course) is vastly
more secure than ShuttlePads.

The ShuttlePads algorithm appears to be a ten-alphabet substitution
cipher with a twist at the end. The twist is vulnerable to a
sum-of-squares comparison of letter frequencies to those of a large
corpus of text; once you've removed the twist, the cipher is wide open
to a Vigenere-style attack, with the added attraction that you don't
have to work out the key size because it's fixed.

If you're just being sarcastic and it's <whoosh>ed over my head, I
apologise.

[MM]

On Thursday, 21 May 2015 01:22:06 UTC+1, Richard Heathfield wrote:
> On 21/05/15 01:11, y wrote:
>
> <snip>
>
> > Sorry for him, this software has a lot of work ( writing it, not thinking ),
>
> If he is still of school age (which seems unlikely), then yes, I feel a
> little bit sorry for him. But if he's a grown-up, he should have learned
> by now that his coding style is inherently inefficient and needs to change.

He is early 80's in age, and is a retired ship's engineer.

M

[Richard Heathfield]

That I didn't know. I'll try to go a bit easier.

[MM]

On Thursday, 21 May 2015 12:40:10 UTC+1, Richard Heathfield wrote:

> On 21/05/15 08:06, MM wrote:
> > He is early 80's in age, and is a retired ship's engineer.
>
> That I didn't know. I'll try to go a bit easier.

Many folks have gone down there. He just gets repetitive and ignores you better.

The classic situation applies; he is a fully-developed crank over email/usenet, but
much more reasonable and thoughtful over the phone.

I speak from first-hand experience.

--

[Jeffrey Goldberg]

I wonder if he is the very nice man I met at PasswordsCon in Las Vegas last
summer. The man, possibily in his 80s, told me that he had a cryptographic
algorithm that would change the world. I told him that he will be met with
extreme skepticism and what he would need to do to overcome it.

I don't know if this is our AOB, and at any rate what he told me was in
confidence, so I won't be any more specific about the conversation.

Cheers,

-j


>

[y]

After this, i have a sincere question: is there something in symetric criptography, ( no Criptanalisis ) that could change the world, i mean, the symetric crypto is so strong this days.
i mean, someone could bring something in symetric crypto that could be considered as NEW and usefull better than the world already know?.

i know, ( excluding quantum crypto ).

if the answer is YES, in what direction would it be. ( new algorithms, new implementations of some specification, new specification, math discoveries )???

-y

[David Eather]

A ship's engineer - without A levels ? Either some form of deckhand or a
very small ship.

[MM]

On Thursday, 21 May 2015 20:20:20 UTC+1, David Eather wrote:
> A ship's engineer - without A levels ? Either some form of deckhand or a
> very small ship.

I have no info on the A-levels. I have a dim memory that he may have done
some Open University courses.

As for rank on board ship, this I do not know. He has said ngineer, which
implies something senior to deckhand or stoker.

Chief Engineer is a rank not far off Captain/Master/Skipper, but that implies
to me a level of analytic thought that I haven't seen expressed online. Other
Engineers (as opposed to stokers) are on the path to Chief Engineer if they
are any good.

M
--

[David Eather]

On Fri, 22 May 2015 07:11:49 +1000, MM <mrvm...@gmail.com> wrote:

> On Thursday, 21 May 2015 20:20:20 UTC+1, David Eather wrote:
>> A ship's engineer - without A levels ? Either some form of deckhand or a
>> very small ship.
>
> I have no info on the A-levels. I have a dim memory that he may have done
> some Open University courses.

Did he pass?

[Robert Wessel]

On Thu, 21 May 2015 12:16:42 -0700 (PDT), y <gici...@gmail.com>
wrote:

No, not really. 128 and 256 bit keys are basically immune to brute
force (with a very small bit of wiggle room for 128 bit keys), so the
only question is whether there are any better attacks. Some things
would be nice, though. An actual proof of the level of security of a
particular algorithm would be nice. Lower resource consumption is
always nice, but AES is pretty fast as it is. Improvements for very
low resource systems would be nice, although the big issues there are
usually not in the symmetric cipher.

[William Unruh]

Well, there are a number of algorithms whose strength I can prove.

Unfortunately you probably also wanted it to be a strong algorithm as
well.

[Robert Wessel]

On Fri, 22 May 2015 00:36:49 +0000 (UTC), William Unruh
<un...@invalid.ca> wrote:

>On 2015-05-22, Robert Wessel <robert...@yahoo.com> wrote:
>> On Thu, 21 May 2015 12:16:42 -0700 (PDT), y <gici...@gmail.com>
>> wrote:
>>
>> No, not really. 128 and 256 bit keys are basically immune to brute
>> force (with a very small bit of wiggle room for 128 bit keys), so the
>> only question is whether there are any better attacks. Some things
>> would be nice, though. An actual proof of the level of security of a
>> particular algorithm would be nice. Lower resource consumption is
>
>Well, there are a number of algorithms whose strength I can prove.
>
>Unfortunately you probably also wanted it to be a strong algorithm as
>well.

True enough - many algorithms have been proven to have approximately
zero security.

While it would be nice to prove that (say) a known plaintext attack on
AES-128 will take at least 2**128 operations, it would be almost as
nice to be able to prove that at least (say) 2**64 would be required.
While that is substantially weaker than the hoped for strength of AES,
we can work with that, if we care.

[MM]

On Friday, 22 May 2015 00:34:39 UTC+1, David Eather wrote:

> On Fri, 22 May 2015 07:11:49 +1000, MM <mrv....@gmail.com> wrote:
>
> > On Thursday, 21 May 2015 20:20:20 UTC+1, David Eather wrote:
> >> A ship's engineer - without A levels ? Either some form of deckhand or a
> >> very small ship.
> >
> > I have no info on the A-levels. I have a dim memory that he may have done
> > some Open University courses.
>
> Did he pass?

No idea, sorry.

M

[Richard Heathfield]

I had kind of assumed (based on the fact that he appears to post from
the PDT time zone) that he was from the United States, but from the
above cultural clues I deduce that he's one of ours, or at least
originates from over here.

I have no doubt that someone from GCHQ monitors this newsgroup. I'd be
interested to hear GCHQ's take on ShuttlePads. Specifically, I'd like to
know what budget they have allocated for cryptanalysing
ShuttlePads-encrypted messages.

Of course, I could simply guess. And, if I were to guess, I'd guess at a
very, very round number.

[y]

What i have seen here is that Cryptalanysis pushes
Cryptology. so in innovation terms, could be a
good advancement to prove that an particular
Algorith is inmune a Cryptanalisis?

you could think, this is impossible, Cryptanalysis
is made it for that. But remember this words
"One Time Pad". hasn't been proven that one time
pad is inmune a cryptoanalysis.

-y

[MM]

On Friday, 22 May 2015 08:12:46 UTC+1, Richard Heathfield wrote:
> I had kind of assumed (based on the fact that he appears to post from
> the PDT time zone) that he was from the United States, but from the
> above cultural clues I deduce that he's one of ours, or at least
> originates from over here.

He sounds Irish (ROI) and he lives in England.

> I have no doubt that someone from GCHQ monitors this newsgroup. I'd be
> interested to hear GCHQ's take on ShuttlePads. Specifically, I'd like to
> know what budget they have allocated for cryptanalysing
> ShuttlePads-encrypted messages.

"It's crap! Next!"

> Of course, I could simply guess. And, if I were to guess, I'd guess at a
> very, very round number.

Yup. THAT round number.

M
--

[y]

El viernes, 22 de mayo de 2015, 10:40:20 (UTC-5), MM escribió:
> On Friday, 22 May 2015 08:12:46 UTC+1, Richard Heathfield wrote:
> > I had kind of assumed (based on the fact that he appears to post from
> > the PDT time zone) that he was from the United States, but from the
> > above cultural clues I deduce that he's one of ours, or at least
> > originates from over here.
>
> He sounds Irish (ROI) and he lives in England.
>

i can't stop thinking how many years he was parenting his IDEA. may be some time was good crypto, ( before cryptoanalisys came to be as advanced as it is today ).
He did not show up at a proper time and now is obsolete.

i hope this was not a intented serius work ( for retirement for example ).

-y

[y]

El miércoles, 20 de mayo de 2015, 19:22:06 (UTC-5), Richard Heathfield escribió:
> On 21/05/15 01:11, y wrote:
>
> <snip>
>
> > Sorry for him, this software has a lot of work ( writing it, not thinking ),
>
> If he is still of school age (which seems unlikely), then yes, I feel a
> little bit sorry for him. But if he's a grown-up, he should have learned
> by now that his coding style is inherently inefficient and needs to change.
>
> > is not a failure becouse the sources compiled.
>
> That's an interesting perspective. :-)
>
> > this code has the beauty of the internal wiring of the enigma machine
>
> No, it doesn't.
>
> > (a famous german encryption machine that has 6 ShuttleRings). and i'm
> > 100% sure that has his great level of security too.
>
> The Enigma (which the Allies did manage to crack, of course) is vastly
> more secure than ShuttlePads.
>
> The ShuttlePads algorithm appears to be a ten-alphabet substitution
> cipher with a twist at the end. The twist is vulnerable to a
> sum-of-squares comparison of letter frequencies to those of a large
> corpus of text; once you've removed the twist, the cipher is wide open
> to a Vigenere-style attack, with the added attraction that you don't
> have to work out the key size because it's fixed.
>
> If you're just being sarcastic and it's <whoosh>ed over my head, I
> apologise.
>

No wasn't antisarcasm, i could add that "Basic language" of the mid 80's was better because his spagetty type programming, could prevent the output from being cryptoanalized.

-y

[Robert Wessel]

On Fri, 22 May 2015 07:28:38 -0700 (PDT), y <gici...@gmail.com>

Huh? OTPs have proven security, and are proof against any
cryptanalysis. OTPs (by themselves) do not hide the length of a
message, which might convey information (for example, if you know the
only two possible messages are "yes" and "no", you know which one it
is based on whether you see two or three bytes go by), nor do they
provide authentication (so a OTP encrypted message is subject to a bit
flipping attack). But an OTP encrypted message cannot be decrypted.

All assuming a proper OTP implementation, of course.

[Richard Heathfield]

On 22/05/15 17:10, y wrote:

<snip>

> No wasn't antisarcasm, i could add that "Basic language"
> of the mid 80's was better because his spagetty type
> programming, could prevent the output from being cryptoanalized.

Only up to the point where it matters enough. If the Belgians were to
occupy Luxembourg, precipitating a major conflict in Europe, and they
were foolish enough to use ShuttlePads for encrypting all their radio
traffic, GCHQ would gather half a dozen Ada experts together and say
"right, sort out this mess", and within the hour all Belgian radio
messages would be laid wide open, spaghetti code or no.

[Rich]

y <gici...@gmail.com> wrote:
> No wasn't antisarcasm, i could add that "Basic language" of the mid
> 80's was better because his spagetty type programming, could prevent
> the output from being cryptoanalized.

Spaghetti code does nothing to prevent the output from being
cryptoanalyzed. An underlying algorithm that successfully obscures
patterns in the output from the input helps to prevent cryptanalysis.

Spaghetti code just puts a very brief hurdle in the way of determining
the algorthim used. Nothing more.

[y]

At the Question: "If you're just being sarcastic and it's <whoosh>ed over my head, I apologise. "
The Answer/
No, wasn't antisarcasm = Yes, Is sarcasm.
( In the most Primitive Cruel form, difficult to cryptanalize
now you have the "key" to decode my comment about "Basic" ).

:)

if OTP has been proven invulnerable to Cryptanalisys why is not being used as standard?

i THINK I HAVE, a good specification for making crypto, i have done some algorithm and implemented it in C# using this specification. and i can assure you, anybody can make an invulnerable algorithm following this specification. ( even the )

Has not been proven, but is easy to conclude because the result is some kind of OTP.

for example: im going to encrypt "0000000000000000" with my algorithm 10 times with the same key.

text -> chypher text
0000000000000000->1EFAF0DAC59B19980ED8396BF505EA
0000000000000000->DCE8F186B57130786A7C74CCE6E697
0000000000000000->E7EB93F1EABA84B1E42B4BACB5E7BE
0000000000000000->6AC8162D479614BA1896F8319DDA89
0000000000000000->F0CAE7E3E13BBEB6F288D8F057A788
0000000000000000->E85AFD7828E370B986554B55C82ADF
0000000000000000->E1EA130D6F8B22862CADF4846C428B
0000000000000000->66ECE4C2092FCC1AC5D8CBCB5602EE
0000000000000000->ECEEB577A3D476441BE3BD2E0F3CDE
0000000000000000->71F0862D3E78207C8FB91F1B2E14C3

if i change 1 bit on the cypher text and decrypt it.

chypher text -> text
71F0862D3E78207C8FB91F1B2E14C2->98FC536CB5FC57C8
61F0862D3E78207C8FB91F1B2E14C3->870275A6AB2B9712

the output is completely different

what makes me think, wy is so hard for others make good crypto?

i can accept, is this is good crypto algorithm? may be not. but...

-y

[Bruce Stephens]

On 22/05/2015 19:35, y wrote:

> if OTP has been proven invulnerable to Cryptanalisys why is not being used as standard?

<http://en.wikipedia.org/wiki/One-time_pad#Problems> gives a reasonable
summary.

<http://en.wikipedia.org/wiki/One-time_pad#Attempt_at_cryptanalysis>
shows why cryptanalysis is pointless.

[William Unruh]

On 2015-05-22, y <gici...@gmail.com> wrote:
> El viernes, 22 de mayo de 2015, 11:50:55 (UTC-5), Rich escribi?:

>> y <gici...@gmail.com> wrote:
>> > No wasn't antisarcasm, i could add that "Basic language" of the mid
>> > 80's was better because his spagetty type programming, could prevent
>> > the output from being cryptoanalized.
>>
>> Spaghetti code does nothing to prevent the output from being
>> cryptoanalyzed. An underlying algorithm that successfully obscures
>> patterns in the output from the input helps to prevent cryptanalysis.
>>
>> Spaghetti code just puts a very brief hurdle in the way of determining
>> the algorthim used. Nothing more.
>
> At the Question: "If you're just being sarcastic and it's <whoosh>ed over my head, I apologise. "
> The Answer/
> No, wasn't antisarcasm = Yes, Is sarcasm.

English is not binary. A double negative is NOT necessarily a positive.
It can be emphasis, it can be denial of the categories used, it can be
many things.

>
> if OTP has been proven invulnerable to Cryptanalisys why is not being used as standard?

It has been invulnerable. It suffers from the problem of key distribtion
and synchronization.

>
> i THINK I HAVE, a good specification for making crypto, i have done some algorithm and implemented it in C# using this specification. and i can assure you, anybody can make an invulnerable algorithm following this specification. ( even the )

At which point you go off the deep end.

>
> Has not been proven, but is easy to conclude because the result is some kind of OTP.

There is no "some kind of OTP". There is OTP and there is not OTP. And
the requirements for being OTP are strict and narrow.

..

> what makes me think, wy is so hard for others make good crypto?

Yes, you should think on that. Very hard.

[William Unruh]

On 2015-05-22, Robert Wessel <robert...@yahoo.com> wrote:
> On Fri, 22 May 2015 07:28:38 -0700 (PDT), y <gici...@gmail.com>
> wrote:
>

>>El jueves, 21 de mayo de 2015, 19:45:38 (UTC-5), robert...@yahoo.com escribi?:

His problem is English, grammer and punctuation. I suspect he meant
"Hasn't it been proven that one time pad is immune to cryptoanalysis?"

> cryptanalysis. OTPs (by themselves) do not hide the length of a
> message, which might convey information (for example, if you know the
> only two possible messages are "yes" and "no", you know which one it
> is based on whether you see two or three bytes go by), nor do they

Nor does almost any secret or public key crypto. It is trial to add
fixed length messages to the requirement. Thus Sure and Nope. or even
"yes" or "no "

> provide authentication (so a OTP encrypted message is subject to a bit
> flipping attack). But an OTP encrypted message cannot be decrypted.

Just as authentication can be added to other cyphers, they can also be
added to otp.

[y]

Sorry for that, my first language is not english. and still learning.

[y]

El viernes, 22 de mayo de 2015, 13:51:35 (UTC-5), William Unruh escribió:
> On 2015-05-22, y <gici...@gmail.com> wrote:
> > El viernes, 22 de mayo de 2015, 11:50:55 (UTC-5), Rich escribi?:
> >> y <gici...@gmail.com> wrote:
> >> > No wasn't antisarcasm, i could add that "Basic language" of the mid
> >> > 80's was better because his spagetty type programming, could prevent
> >> > the output from being cryptoanalized.
> >>
> >> Spaghetti code does nothing to prevent the output from being
> >> cryptoanalyzed. An underlying algorithm that successfully obscures
> >> patterns in the output from the input helps to prevent cryptanalysis.
> >>
> >> Spaghetti code just puts a very brief hurdle in the way of determining
> >> the algorthim used. Nothing more.
> >
> > At the Question: "If you're just being sarcastic and it's <whoosh>ed over my head, I apologise. "
> > The Answer/
> > No, wasn't antisarcasm = Yes, Is sarcasm.
>
> English is not binary. A double negative is NOT necessarily a positive.
> It can be emphasis, it can be denial of the categories used, it can be
> many things.
>
> >
> > if OTP has been proven invulnerable to Cryptanalisys why is not being used as standard?
>
> It has been invulnerable. It suffers from the problem of key distribtion
> and synchronization.
>
> >
> > i THINK I HAVE, a good specification for making crypto, i have done some algorithm and implemented it in C# using this specification. and i can assure you, anybody can make an invulnerable algorithm following this specification. ( even the )
>
> At which point you go off the deep end.

i was going to say ( even the common programmer ) can make good crypto following the specification i mention in that paragraph.
but i stopped, it must first be confirmed in some way.

>
> >
> > Has not been proven, but is easy to conclude because the result is some kind of OTP.
>
> There is no "some kind of OTP". There is OTP and there is not OTP. And
> the requirements for being OTP are strict and narrow.
>

Yes, the OTP im talking about, allow the sender of the message to choose the pad on the fly. and the distribution is not a problem (not possible leakage of the pad ). so is different in the fact that some weakness of the OTP, are overcomed. if the OTP needs to have those weakness. so is not OTP, but is like an OTP.

[Robert Wessel]

On Fri, 22 May 2015 12:32:53 -0700 (PDT), y <gici...@gmail.com>

No, such a thing would *not* be "like an OTP", but it might be like a
stream cipher. An OTP has very severe rules for *how* the pad is
generated. No algorithmic method, which you seem to imply, can
generate a pad for an OTP. Again, an algorithmically generated pad is
a stream cipher.

You would hardly be the first to confuse the operation of an OTP,
where the stream of pad characters is added/xor'd/whatever to the
plaintext stream, with the real essence of OTP, which is how the pad
is generated. The generation of the pad requires that each bit in the
pad be unpredictable and entirely unrelated to any other bit in the
pad.

Consider that a house is not "like a car" because you've observed that
it, like a car, has a roof and doors.

Good cryptographic algorithms are hard, especially if you care about
economy of key bit usage.

[William Unruh]

>>
> Yes, the OTP im talking about, allow the sender of the message to choose the pad on the fly. and the distribution is not a problem (not possible leakage of the pad ). so is different in the fact that some weakness of the OTP, are overcomed. if the OTP needs to have those weakness. so is not OTP, but is like an OTP.

If the sender chooses the OTP on the fly then there is no way the
recipient knows what it is, and cannot decrypt it. That is not crypto.
If the sender sends the OTP to the recipient, then an Evesdropper can
itnercept it. If the receiver can generate the same OTP then the system
is not an OTP but maybe some sort of stream cypher..

[William Unruh]

On 2015-05-22, y <gici...@gmail.com> wrote:

>> >>"One Time Pad". hasn't been proven that one time
>> >>pad is inmune a cryptoanalysis.
>> >
>> >
>> > Huh? OTPs have proven security, and are proof against any
>>
>> His problem is English, grammer and punctuation. I suspect he meant
>> "Hasn't it been proven that one time pad is immune to cryptoanalysis?"
>
> Sorry for that, my first language is not english. and still learning.

Capital letters at the beginning of sentences, and question marks are a
feature of all languages I know. What you produced was due to
carelessness not lack of knowledge of English.

[Rob Warnock]

William Unruh <un...@invalid.ca> wrote:
+---------------

| English is not binary. A double negative is NOT necessarily
| a positive. It can be emphasis, it can be denial of the
| categories used, it can be many things.

+---------------

Reminds me of the old joke:

A professor lecturing on comparative languages pontificated thusly:

"In Russian a double negative just makes the negation stronger,
while in English a double negative makes a positive. But there
are no known languages in which a double positive makes a negative".

From the back of the room came this laconic heckle:

"Yeah, right."


-Rob

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403

[y]

Have you take in account that i have to think what im going to say, how is the translation, and how is the correct spelling, cheking the result, yes i forget sometimes the capitalization. and the puntuation. :) is the problem for not to be a native speaker in any language. but off course, i like to make thinks perfect event the pronunciation. Thanks for point it out.

-y

[y]

>
>No, such a thing would *not* be "like an OTP", but it might be like a
>stream cipher. An OTP has very severe rules for *how* the pad is
>generated. No algorithmic method, which you seem to imply, can
>generate a pad for an OTP. Again, an algorithmically generated pad is
>a stream cipher.
>
>You would hardly be the first to confuse the operation of an OTP,
>where the stream of pad characters is added/xor'd/whatever to the
>plaintext stream, with the real essence of OTP, which is how the pad
>is generated. The generation of the pad requires that each bit in the
>pad be unpredictable and entirely unrelated to any other bit in the
>pad.
>
>Consider that a house is not "like a car" because you've observed that
>it, like a car, has a roof and doors.
>
>Good cryptographic algorithms are hard, especially if you care about
>economy of key bit usage.
>

---------------- ------------------ ------------------ ----------------

>
>If the sender chooses the OTP on the fly then there is no way the
>recipient knows what it is, and cannot decrypt it. That is not crypto.
>If the sender sends the OTP to the recipient, then an Evesdropper can
>itnercept it. If the receiver can generate the same OTP then the system
>is not an OTP but maybe some sort of stream cypher..
>

Any talking starting with OTP related to my algorithm, i would have a
broken argument because of this, have no previous knowledge of OTP
before i made my specs and algorithm. *after that, i change nothing.

I have to admit, i made my specification and found it very good ( at my
point of view ). later, i implement it in c#. the cypher worked as spected.
( level of security :s *still to be proven or accepted widely ) i started
to make some research and found two references, FEISTEL STRUCTURE. OTP.
that are correlated with my specs. ( i found others but this are the main ).
The first for be a good specification. and the other for his strength.

-At this point must be obvious im a noob in crypto. last 3 months of interest
only. wich implies ( may be, im talkin garbage )-

After studing ( not carefully ), possible types of ( general attacks ).
i come with my specs, but without previous knowledge i found the need of
the rounds, i found the need of key schedule, i found the need of a IV,
and this is the good part for me: i found the need of other tree more
concepts. ( some of them were applied in my specification. ).

For that reason i start to making some research and found this:
IV : whas nothing new.
Key schedule : was nothing new.
iterating for the same crypto ( rounds ) : was nothing new.
( The process was a little bit of trouble -remember i have no previous
knowledge and my goal was found correlated process - ).

BUT, the other tree new process, - im not sure if there is something
out there or they are new. i can say this: i found nothing correlated YET.
the only possibly clue, is that making today's crypto is normally hard, and
with my specification, making crypto will be easyer for anyone normally.

This is true if my claims are true. ( still to prove of course ): a multitude
of public algorithms each one of them in the same strength. and working for
private communications* this is the result. If anyone can make good crypto.
for programmer that make his software, and now does not have to trust in the
strength of the public wide spread algorithms for his private crypto.

I think this approach is new ( is new for everyone of you? ), i have to
prove a lot of things.

As a side note: this is not my first try, i have failed many times
( in 3 months :s ) and found by my self the weakness in my algorithms.
For my current specs and algorithm, is hard to found a weakness, i have no
starting point. ( only brute force ).

-y

[y]

El sábado, 23 de mayo de 2015, 3:25:05 (UTC-5), Rob Warnock escribió:
> William Unruh <un...@invalid.ca> wrote:
> +---------------
> | English is not binary. A double negative is NOT necessarily
> | a positive. It can be emphasis, it can be denial of the
> | categories used, it can be many things.
> +---------------
>
> Reminds me of the old joke:
>
> A professor lecturing on comparative languages pontificated thusly:
>
> "In Russian a double negative just makes the negation stronger,
> while in English a double negative makes a positive. But there
> are no known languages in which a double positive makes a negative".

is funny, language is not binary, is like Math. and Russian is in complex numbers of course. Chinnese is like failed crypto, just like the wall :)

http://en.wikipedia.org/wiki/Double_negative

-y

[Rich]

Perhaps some "before/after" would be good. Your above paragraph, after
editing, would be much improved were it written this way:

> Have you taken into account that I have to think about what I'm going
> to say, what the translation should be, and what spelling is correct?
> In checking the result, yes I sometimes forget the capitalization and
> the punctuation. :) This is the problem when one is not a native
> speaker in any language. but of course, I would like to make it
> perfect, even the pronunciation. Thanks for pointing it out.

[Gordon Burditt]

> Alice encrypts plaintext to get Bob's ciphertext.
>
> Using the very same function Bob can encrypt Alice's ciphertext
> to get back to her Plaintext.

You're not using "the very same function", you're using "the inverse
of the very same function". In an involutional cipher, the encryption
function is its own inverse. In a non-involutional cipher, it isn't.

> f(P) = C
> F^-1() = P
f(C) = P

> Bob's decryption is the inverse of Alices encryption function ? - adacrypt

In an involutional cipher, the encryption and decryption functions
are the same, (and are self-inverses) and you don't have to specify
whether you are encrypting or decrypting.

f(f(P)) = P, for all values of P and all possible keys.

Examples of involutional ciphers:
ROT 13*K, where K is an integer, the key (some cipher - only 2
possible distinct keys).
A stream cipher using bitwise XOR with a stream.

Examples of non-involutional ciphers:
ROT 7*K, where K is an integer, the key. (some cipher - only 26
possible distinct keys).
A stream cipher using binary ADD with end-around-carry with a stream.
Shuttlepads
Morse Code (the plaintext and ciphertext alphabets have to be the
same for an involutional cipher).

[David Eather]

On Fri, 22 May 2015 09:34:35 +1000, David Eather <eat...@tpg.com.au> wrote:

> On Fri, 22 May 2015 07:11:49 +1000, MM <mrvm...@gmail.com> wrote:
>
>> On Thursday, 21 May 2015 20:20:20 UTC+1, David Eather wrote:
>>> A ship's engineer - without A levels ? Either some form of deckhand or
>>> a
>>> very small ship.
>>
>> I have no info on the A-levels. I have a dim memory that he may have
>> done
>> some Open University courses.
>
> Did he pass?
>
>>

>> As for rank on board ship, this I do not know. He has said ngineer,
>> which
>> implies something senior to deckhand or stoker.
>>
>> Chief Engineer is a rank not far off Captain/Master/Skipper, but that
>> implies
>> to me a level of analytic thought that I haven't seen expressed online.
>> Other
>> Engineers (as opposed to stokers) are on the path to Chief Engineer if
>> they
>> are any good.
>>
>> M

Oops - I've been a bit harsh. AOB grew up before the very stupid era of "I
don't care if you can do the job or not - if you don't have the piece of
parer we can't employ you", so it might be possible for him to have the
position he claimed. "Might be possible" is as far as I will go.