Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.crypt > #32786 > unrolled thread

Introduction me

Back to article view | Back to sci.crypt

Contents

  Introduction me eaglesondouglas@gmail.com - 2015-10-12 10:26 -0700
    Re: Introduction me Rich <rich@example.invalid> - 2015-10-12 17:45 +0000
      Re: Introduction me eaglesondouglas@gmail.com - 2015-10-13 08:28 -0700
        Re: Introduction me William Unruh <unruh@invalid.ca> - 2015-10-13 16:09 +0000
        Re: Introduction me Rich <rich@example.invalid> - 2015-10-13 16:19 +0000
    Re: Introduction me William Unruh <unruh@invalid.ca> - 2015-10-12 17:46 +0000
      Re: Introduction me Karl-Uwe Frank <karl.frank@freecx.co.uk> - 2015-10-12 21:19 +0200
        Re: Introduction me Rich <rich@example.invalid> - 2015-10-12 20:24 +0000
          Re: Introduction me Johan Wevers <johanw@vulcan.xs4all.nl> - 2015-10-13 10:08 +0200
            Re: Introduction me Rich <rich@example.invalid> - 2015-10-13 16:20 +0000
            Re: Introduction me Rich <rich@example.invalid> - 2015-10-13 16:24 +0000
              Re: Introduction me Nomen Nescio <nobody@dizum.com> - 2015-10-14 16:20 +0200
    Re: Introduction me Ribeiro Alvo <ribeiroalvo@gmail.com> - 2015-10-13 03:58 -0700
    Re: Introduction me "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-10-13 14:35 -0700
      Re: Introduction me William Unruh <unruh@invalid.ca> - 2015-10-13 22:28 +0000
        Re: Introduction me "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-10-14 14:54 -0700
          Re: Introduction me Rich <rich@example.invalid> - 2015-10-14 22:02 +0000
            Re: Introduction me gordonb.loovx@burditt.org (Gordon Burditt) - 2015-10-15 02:39 -0500
              Re: Introduction me William Unruh <unruh@invalid.ca> - 2015-10-15 08:00 +0000
            Re: Introduction me Richard Heathfield <rjh@cpax.org.uk> - 2015-10-15 13:14 +0100
              Re: Introduction me "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-10-15 12:13 -0700
                Re: Introduction me "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-10-15 12:35 -0700
                Re: Introduction me Rich <rich@example.invalid> - 2015-10-15 22:34 +0000
                  Re: Introduction me "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-10-16 01:15 -0700
                    Re: Introduction me William Unruh <unruh@invalid.ca> - 2015-10-16 18:02 +0000
                      Re: Introduction me wizzofozz <oscxxxxxxxaas@gmail.com> - 2015-10-16 20:30 +0200
                        Re: Introduction me Rich <rich@example.invalid> - 2015-10-16 20:09 +0000
                          Re: Introduction me "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-10-19 14:45 -0700
                Re: Introduction me William Unruh <unruh@invalid.ca> - 2015-10-15 23:16 +0000
          Re: Introduction me William Unruh <unruh@invalid.ca> - 2015-10-14 22:48 +0000
    Re: Introduction me eaglesondouglas@gmail.com - 2015-10-14 08:03 -0700
      Re: Introduction me omnilobe@gmail.com - 2015-10-14 10:23 -0700
        Re: Introduction me William Unruh <unruh@invalid.ca> - 2015-10-14 17:34 +0000
    Re: Introduction me eaglesondouglas@gmail.com - 2015-10-15 07:21 -0700
    Re: Introduction me Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-18 12:56 -0500
      Re: Introduction me MM <mrvmurray@gmail.com> - 2015-10-18 11:44 -0700
      Re: Introduction me rpw3@rpw3.org (Rob Warnock) - 2015-10-18 18:57 +0000
        Re: Introduction me Jeffrey Goldberg <nobody@goldmark.org> - 2015-10-19 17:52 -0500

Page 2 of 2 — ← Prev page 1 [2]

#32961

>"Richard Heathfield" wrote in message news:mvo57c$ubk$1@dont-email.me...

>>On 14/10/15 23:02, Rich wrote:
>>> Chris M. Thomasson <nospam@nospam.nospam> wrote:
[...]
>>> FWIW, I converted the ciphertext into hexbytes in ASCII because I
>>> liked the way Richard Heathfield presented his ciphertext challenges
>>> to this group. It worked great!
>>
>> It was necessary for posting to the group to insure that various NNTP
>> transports and viewers did not corrupt the data.

> The advantages of the method I used were:

[snip advantages of hexbytes in ASCII]

> The disadvantage was that it takes three bytes (two hexits and a space) to 
> represent one byte. This isn't ciphertext inflation as such, because it's 
> only the rather naff transport mechanism that's to blame, not the 
> algorithm, and the inflation gets punctured by the tool that reconstructs 
> the binary from the hex data.

Exactly right. The inflation in not the fault of the algorithm, its part
of the “convenience” of showing the ciphertext in ASCII hexbytes. I not
not need to add the space between each hexbyte, but it sure makes them
easier to see individually!  ;^)


> >> What do you think about using a checkbox that allows a user to generate
> >> ASCII hexbytes or raw output dumped into the ciphertext textarea?
> >
> > A very bad idea.

> Doesn't that rather depend on his objectives? If his intent is, say, for 
> people to grab the ciphertext so that they can (literally) have a crack at 
> it on their home machines, then the above may well make this easier for 
> them, which would be a good thing, right? It sure beats copying and 
> pasting 8947h ry4ifabdklf r4yu89w4 $^&*( from an output window.

This is exactly why I did it Richard, and I am sorry for not making this 
clear.

;^(

Also, I am worried about a “cut-and-paste” keeping all of the non-printable
characters, such as null bytes from a textarea in HTML5. I need to test this
by filling a textarea A with a bunch of nulls and other non-printable 
characters,
then copy it over to another textarea B and validating that A = B.

My Javascript and HTML5 skills are a bit rusty!

;^/


Therefore, I think adding a checkbox wrt displaying the ciphertext in ASCII
hexbytes
is a good thing?

Humm... 

[toc] | [prev] | [next] | [standalone]

#32963

> "Chris M. Thomasson"  wrote in message 
> news:mvottj$r0e$1@speranza.aioe.org...

>>"Richard Heathfield" wrote in message news:mvo57c$ubk$1@dont-email.me...

[...]

> I not not need to add the space between each hexbyte, but it sure makes 
> them
> easier to see individually!  ;^)

Damn double negative! Anyway, I meant:

I do not need to add the space between each hexbyte, but it sure makes them 
easier
to see individually!

;^/ 

[toc] | [prev] | [next] | [standalone]

#32971

Chris M. Thomasson <nospam@nospam.nospam> wrote:
> >"Richard Heathfield" wrote in message news:mvo57c$ubk$1@dont-email.me...

> >>On 14/10/15 23:02, Rich wrote:
> >>> Chris M. Thomasson <nospam@nospam.nospam> wrote:
> [...]
> > >> What do you think about using a checkbox that allows a user to
> > >> generate ASCII hexbytes or raw output dumped into the ciphertext
> > >> textarea?
> > >
> > > A very bad idea.

> > Doesn't that rather depend on his objectives? If his intent is,
> > say, for people to grab the ciphertext so that they can (literally)
> > have a crack at it on their home machines, then the above may well
> > make this easier for them, which would be a good thing, right? It
> > sure beats copying and pasting 8947h ry4ifabdklf r4yu89w4 $^&*(
> > from an output window.

> This is exactly why I did it Richard, and I am sorry for not making
> this clear.

> ;^(

Thanks for the clarification, yes this was not clear.  In fact you are
still not being overly clear.  Are you building a "viewing interface"
which would sit in front of the crypto algorithm and provide different
visuals to someone using the interface?  Because my initial response
was based upon my misinterpretation that you were modifying the
crypto algorithm itself to only work with ASCII (as in turning it into
an AOB algorithm).

> Also, I am worried about a ?cut-and-paste? keeping all of the
> non-printable characters, such as null bytes from a textarea in
> HTML5. I need to test this by filling a textarea A with a bunch of
> nulls and other non-printable characters, then copy it over to
> another textarea B and validating that A = B.

> My Javascript and HTML5 skills are a bit rusty!

> ;^/

Ok, so you are building an HTML5 'tool' that would allow someone to
enter a message in box 1, push a button, and have the encrypted version
appear in box 2?  Is that what you are building?  If so, then having a
'checkbox' in the interface to control the visual formatting of the
output makes sense.

I had misinterpreted your 'checkbox' (due to the lack of clarity) to be
a modification of the algorithm to only consume and/or output ASCII.

> Therefore, I think adding a checkbox wrt displaying the ciphertext in
> ASCII hexbytes is a good thing?

> Humm... 

If you are talking in a user interface for visualizing, then it is
reasonable.  I think this is what you are talking about now.

[toc] | [prev] | [next] | [standalone]

#32992

> "Rich" wrote in message news:mvp9kt$ksp$1@dont-email.me...

> > Chris M. Thomasson <nospam@nospam.nospam> wrote:
> > >"Richard Heathfield" wrote in message 
> > >news:mvo57c$ubk$1@dont-email.me...

> > >>On 14/10/15 23:02, Rich wrote:
> > >>> Chris M. Thomasson <nospam@nospam.nospam> wrote:
> > [...]
> > > >> What do you think about using a checkbox that allows a user to
> > > >> generate ASCII hexbytes or raw output dumped into the ciphertext
> > > >> textarea?
> > > >
> > > > A very bad idea.

> > > Doesn't that rather depend on his objectives? If his intent is,
> > > say, for people to grab the ciphertext so that they can (literally)
> > > have a crack at it on their home machines, then the above may well
> > > make this easier for them, which would be a good thing, right? It
> > > sure beats copying and pasting 8947h ry4ifabdklf r4yu89w4 $^&*(
> > > from an output window.

> > This is exactly why I did it Richard, and I am sorry for not making
> > this clear.

> > ;^(

> Thanks for the clarification, yes this was not clear.

No problem, and sorry for any confusions I have caused.  ;^/



> In fact you are
> still not being overly clear. Are you building a "viewing interface"
> which would sit in front of the crypto algorithm and provide different
> visuals to someone using the interface?

Yes.


> Because my initial response
> was based upon my misinterpretation that you were modifying the
> crypto algorithm itself to only work with ASCII (as in turning it into
> an AOB algorithm).

No!   :^)



> > Also, I am worried about a ?cut-and-paste? keeping all of the
> > non-printable characters, such as null bytes from a textarea in
> > HTML5. I need to test this by filling a textarea A with a bunch of
> > nulls and other non-printable characters, then copy it over to
> > another textarea B and validating that A = B.

> > My Javascript and HTML5 skills are a bit rusty!

> > ;^/

> Ok, so you are building an HTML5 'tool' that would allow someone to
> enter a message in box 1, push a button, and have the encrypted version
> appear in box 2? Is that what you are building?

Yes.



> If so, then having a
> 'checkbox' in the interface to control the visual formatting of the
> output makes sense.

I thought it would.



> I had misinterpreted your 'checkbox' (due to the lack of clarity) to be
> a modification of the algorithm to only consume and/or output ASCII.

This checkbox would allow a user to visualize the ciphertext in ASCII 
hexbytes.



> > Therefore, I think adding a checkbox wrt displaying the ciphertext in
> > ASCII hexbytes is a good thing?

> > Humm...

> If you are talking in a user interface for visualizing, then it is
> reasonable. I think this is what you are talking about now.

Exactly correct, and I thank you for your patience Rich!

:^) 

[toc] | [prev] | [next] | [standalone]

#33004

On 2015-10-16, Chris M. Thomasson <nospam@nospam.nospam> wrote:
>> "Rich" wrote in message news:mvp9kt$ksp$1@dont-email.me...
>
>> > Chris M. Thomasson <nospam@nospam.nospam> wrote:
>> > >"Richard Heathfield" wrote in message 
>> > >news:mvo57c$ubk$1@dont-email.me...
>
>> > >>On 14/10/15 23:02, Rich wrote:
>> > >>> Chris M. Thomasson <nospam@nospam.nospam> wrote:
>> > [...]
>> > > >> What do you think about using a checkbox that allows a user to
>> > > >> generate ASCII hexbytes or raw output dumped into the ciphertext
>> > > >> textarea?
>> > > >
>> > > > A very bad idea.
>
>> > > Doesn't that rather depend on his objectives? If his intent is,
>> > > say, for people to grab the ciphertext so that they can (literally)
>> > > have a crack at it on their home machines, then the above may well
>> > > make this easier for them, which would be a good thing, right? It
>> > > sure beats copying and pasting 8947h ry4ifabdklf r4yu89w4 $^&*(
>> > > from an output window.
>
>> > This is exactly why I did it Richard, and I am sorry for not making
>> > this clear.
>
>> > ;^(
>
>> Thanks for the clarification, yes this was not clear.
>
> No problem, and sorry for any confusions I have caused.  ;^/
>
>
>
>> In fact you are
>> still not being overly clear. Are you building a "viewing interface"
>> which would sit in front of the crypto algorithm and provide different
>> visuals to someone using the interface?
>
> Yes.

But your statement that you wanted to strip off the 8th bit and present
that in a different file, and the formatting in yet another file seems
to belie that.

[toc] | [prev] | [next] | [standalone]

#33007

On 16-10-2015 20:02, William Unruh wrote:
> On 2015-10-16, Chris M. Thomasson <nospam@nospam.nospam> wrote:
>>
>>> In fact you are
>>> still not being overly clear. Are you building a "viewing interface"
>>> which would sit in front of the crypto algorithm and provide different
>>> visuals to someone using the interface?
>>
>> Yes.
> 
> But your statement that you wanted to strip off the 8th bit and present
> that in a different file, and the formatting in yet another file seems
> to belie that.
> 

Your confusing Chris with the OP.

@chris: maybe you should run the cipher serverside, as opposed to
clientside in javascript, so that you can simply spit out a file which
the user downloads.

Ozz

[toc] | [prev] | [next] | [standalone]

#33008

wizzofozz <oscxxxxxxxaas@gmail.com> wrote:
> On 16-10-2015 20:02, William Unruh wrote:
> > On 2015-10-16, Chris M. Thomasson <nospam@nospam.nospam> wrote:
> >>
> >>> In fact you are still not being overly clear. Are you building a
> >>> "viewing interface" which would sit in front of the crypto
> >>> algorithm and provide different visuals to someone using the
> >>> interface?
> >>
> >> Yes.
> > 
> > But your statement that you wanted to strip off the 8th bit and
> > present that in a different file, and the formatting in yet another
> > file seems to belie that.
> > 

> Your confusing Chris with the OP.

> @chris: maybe you should run the cipher serverside, as opposed to
> clientside in javascript, so that you can simply spit out a file
> which the user downloads.

I have a suspision (again, @chris could clarify better) that he may
also intend this HTML5 JS app. that he is writing to be a full client
side system, no server involved.

But until @chris clarifies, I have only a suspision.

@chris, you might also consider starting a new, separate, thread
instead of adding to an existing one like in this case, it would mean
less likelyhood of your discussion of your system getting mixed up
with, in this case, the original posters system.

[toc] | [prev] | [next] | [standalone]

#33067

> "Rich" wrote in message news:mvrlhc$9ge$1@dont-email.me... 

> > wizzofozz <oscxxxxxxxaas@gmail.com> wrote:
>> >  On 16-10-2015 20:02, William Unruh wrote:
> > >>  On 2015-10-16, Chris M. Thomasson <nospam@nospam.nospam> wrote:

> > >>> In fact you are still not being overly clear. Are you building a
> > >>> "viewing interface" which would sit in front of the crypto
> > >>> algorithm and provide different visuals to someone using the
> > >>> interface?

> > >> Yes.

> > > But your statement that you wanted to strip off the 8th bit and
> > > present that in a different file, and the formatting in yet another
> > > file seems to belie that.


> > Your confusing Chris with the OP.


> > @chris: maybe you should run the cipher serverside, as opposed to
> > clientside in javascript, so that you can simply spit out a file
> > which the user downloads.


> I have a suspision (again, @chris could clarify better) that he may
> also intend this HTML5 JS app. that he is writing to be a full client
> side system, no server involved.

> But until @chris clarifies, I have only a suspision.

Your suspicion is correct Rich. I am use a free webhosting site (atspace), 
and am worried about a server side program being timeshared too much, 
or being limited wrt processing time. Therefore, a client-side only  
solution seems very attractive for now...

> @chris, you might also consider starting a new, separate, thread
> instead of adding to an existing one like in this case, it would mean
> less likelyhood of your discussion of your system getting mixed up
> with, in this case, the original posters system.

Agreed. I am adding some more functionality wrt how a user can visualize 
the data. The new visualization abilities include byte frequency graphs 
for the cyphertext. I will make a new thread once that is completed.

FWIW, I am programming this as an online tool to be used in conjunction 
with the paper I am writing.

[toc] | [prev] | [next] | [standalone]

#32979

On 2015-10-15, Chris M. Thomasson <nospam@nospam.nospam> wrote:
>>"Richard Heathfield" wrote in message news:mvo57c$ubk$1@dont-email.me...
>
>> Doesn't that rather depend on his objectives? If his intent is, say, for 
>> people to grab the ciphertext so that they can (literally) have a crack at 
>> it on their home machines, then the above may well make this easier for 
>> them, which would be a good thing, right? It sure beats copying and 
>> pasting 8947h ry4ifabdklf r4yu89w4 $^&*( from an output window.

But that is what a uuencoded file looks like:-)

[toc] | [prev] | [next] | [standalone]

#32893

On 2015-10-14, Chris M. Thomasson <nospam@nospam.nospam> wrote:
>> "William Unruh" wrote in message news:mvk0hh$mf0$1@dont-email.me...
>
>> > On 2015-10-13, Chris M. Thomasson <nospam@nospam.nospam> wrote:
>> > wrote in message
>> > news:9abd4bb5-a4a2-4504-96e5-dba3ac39cdc6@googlegroups.com...
> [...]
>
>> > WRT ASCII, I basically had to make the online version of my cipher 
>> > convert a
>> > plaintext into a series of
>> > hexbytes in ASCII so that a user would not get a bunch of trash in the
>> > ciphertext:
>> >
>> > http://funwithfractals.atspace.cc/ffe
>> >
>> > IMHO, I think encrypting the plaintext into a ciphertext of hexbytes wrt 
>> > the
>> > online version is a good thing
>> > because a user can easily take a look at every byte of the ciphertext.
>
>> And why does the user waht to look at any byte of the ciphertext?
>> Sounds like a pretty pointless exercise.
>
>
> That is fair enough William.
>
> I can easily turn off the hexbyte conversion process, but then the
> ciphertext will be a bunch of ???gobbledygook??? that is not going to be
> pleasing to the eye of somebody who wants to visually examine it. What
> if a user wants to examine the ciphertext directly without having to
> look at a bunch of random symbols and non-printable characters directly
> in the webpage?

And why would they want to do that? 
There is no information whatsoever in the cyphertext. (well of course
that is not really true, but that information is revealed only by use of
the key and decryption. The encrypted cyphertext looks like random data
to all reasonable tests.)


>
> Ahhh! I should make this an option, perhaps via checkbox that will
> allow a user to see the hexbytes if they want to.

Why?

>
> FWIW, I converted the ciphertext into hexbytes in ASCII because I
> liked the way Richard Heathfield presented his ciphertext challenges
> to this group. It worked great!

IF you want to transfer the cyphertext over a channel which only accepts
ascii, which is what newsnet does, then conversion to ascii could be
useful, not to examine it, but purely in order to transfer it via that
medium.

>
> What do you think about using a checkbox that allows a user to generate
> ASCII hexbytes or raw output dumped into the ciphertext textarea?

Pointless. 

If they want to have ascii encoding, then there exist loads of ways to
do that (eg uuencode, or hex bytes.)

[toc] | [prev] | [next] | [standalone]

#32882

Thanks for the comments.  I obviously need to take a step backward. Maybe look at message modeling concepts.

From what I am seeing behavior wise is that the Notepad program decodes as ASCI one. Some programs decode as UNICODE as an option.  

The end point for my application attempt is to have ASCI one printouts that can be copied and scanned in for Optical Character Recognition reassembly to the desired format.   

Thanks again!
Doug
eaglessondouglas@gmail.com 

[toc] | [prev] | [next] | [standalone]

#32883

On Wednesday, October 14, 2015 at 5:03:50 AM UTC-10, eagleso...@gmail.com wrote:
> Thanks for the comments.  I obviously need to take a step backward. Maybe look at message modeling concepts.
> 
> From what I am seeing behavior wise is that the Notepad program decodes as ASCI one. Some programs decode as UNICODE as an option.  
> 
> The end point for my application attempt is to have ASCI one printouts that can be copied and scanned in for Optical Character Recognition reassembly to the desired format.   
> 
> Thanks again!
> Doug
> ea

Dear Doug, Welcome to sci.crypt !
Your ASCII plan can be improved by using The Parity Bit, or as you call it " the 8th bit". Since it is a parity bit, you can control its value by making the other 7 bit have a parity that is logical. An even number of '1's in the 7 bits will set the parity bit to '1'. Than you can just select words with certain parities to have a second channel.

ASCII is now replaced by UNICODE.
see my Cuneiform Unicode Steganography website.
I read Cuneiform to decrypt my passwords.

[toc] | [prev] | [next] | [standalone]

#32884

On 2015-10-14, omnilobe@gmail.com <omnilobe@gmail.com> wrote:
> On Wednesday, October 14, 2015 at 5:03:50 AM UTC-10, eagleso...@gmail.com wrote:
>> Thanks for the comments.  I obviously need to take a step backward. Maybe look at message modeling concepts.
>> 
>> From what I am seeing behavior wise is that the Notepad program decodes as ASCI one. Some programs decode as UNICODE as an option.  
>> 
>> The end point for my application attempt is to have ASCI one printouts that can be copied and scanned in for Optical Character Recognition reassembly to the desired format.   
>> 
>> Thanks again!
>> Doug
>> ea
>
> Dear Doug, Welcome to sci.crypt !
> Your ASCII plan can be improved by using The Parity Bit, or as you call it " the 8th bit". Since it is a parity bit, you can control its value by making the other 7 bit have a parity that is logical. An even number of '1's in the 7 bits will set the parity bit to '1'. Than you can just select words with certain parities to have a second channel.

No the eight-th bit is not a parity bit. It is an extended ascii. And if
yo try to force it to be a certain value, half of the ascii letters
would be unseable Not a good thing. I know people have written books
never using the letter e, but to not use half the alphabet might be a
challenge noone can meet.

>
> ASCII is now replaced by UNICODE.
> see my Cuneiform Unicode Steganography website.
> I read Cuneiform to decrypt my passwords.

And this servers what purpose. It makes it no harder to break your
password, but makes it much harder for you to use them. 

[toc] | [prev] | [next] | [standalone]

#32946

To: William Unruh

Thanks for the 8 bit warning. I need to segregate algorithm input/output type from display type.

Your concept of using UUENCODE appears quite sufficient at creating my printable ciphertext.

In the realm of thinking about vulnerability due to header and format commands the concept of multiple UUENCODE arises.  If the attacker has unknown content no attack will be fruitful.  UUENCODing-UUENCODE ends format apriori. So I need no multiple messages for reassembly.

Douglas Eagleson
eaglesondouglas@gmail.com

[toc] | [prev] | [next] | [standalone]

#33044

On 2015-10-12 17:26:33 +0000, eaglesondouglas@gmail.com said:

> MY site:
> 
> https://www.sites.google.com/site/douglaseaglesongaithersburgmd/
> 
> I did try my hand once at a real application in java, 15 years ago.  Go 
> to the "MY Files" field to get to all my public work.  The "crypto" 
> folder has the java classes there.  It is a hidden function modified 
> DES for ASCI files only.

Hi Doug,

We can't get to those files.

You can see more of YOUR files on your site than we can. So for us 
visiting your site, there is no such thing as "My Files". Please place 
links to those in a way that they are publicly available.

Thanks!

-j

[toc] | [prev] | [next] | [standalone]

#33046

On Sunday, 18 October 2015 18:56:34 UTC+1, Jeffrey Goldberg  wrote:
> We can't get to those files.

I can, at least with Google Groups. The "My Files" link is near the bottom
of the page linked to by the OP's URI.

M
-- 

[toc] | [prev] | [next] | [standalone]

#33047

Jeffrey Goldberg  <jeffrey+news@goldmark.org> wrote:
+---------------
| eaglesondouglas@gmail.com said:
| > MY site:
| > https://www.sites.google.com/site/douglaseaglesongaithersburgmd/
| > 
| > I did try my hand once at a real application in java, 15 years ago.
| > Go to the "MY Files" field to get to all my public work.  The "crypto" 
| > folder has the java classes there.  It is a hidden function modified 
| > DES for ASCI files only.
| 
| Hi Doug,
| 
| We can't get to those files.
| 
| You can see more of YOUR files on your site than we can. So for us 
| visiting your site, there is no such thing as "My Files". Please place 
| links to those in a way that they are publicly available.
+---------------

Actually, if one scrolls almost all the way down to
the bottom of the text, one finds a "My Files" link
embedded in the text that seems to work. From there,
the icons "crypto" then "des" lead to some stuff.
But I'm not sure anyone will find it useful. Snippets
from the "readme.txt":

    An ASCII encoded file crypto application by Douglas Eagleson
    ...
    A modified DES Implementation, NIST: FIPS PUB 46-2, 1993-
    The S-box relation was removed making it a complete shuffle.
    ...
    The s-block values within this implementation have been
    changed so that there is no way to encypt/decrypt a
    Standard DES implementation.


-Rob

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

[toc] | [prev] | [next] | [standalone]

#33069

On 2015-10-18 18:57:03 +0000, Rob Warnock said:

> Jeffrey Goldberg  <jeffrey+news@goldmark.org> wrote:
> | We can't get to those files.


> 
> Actually, if one scrolls almost all the way down to
> the bottom of the text, one finds a "My Files" link
> embedded in the text that seems to work.

Ah. Thanks. (and also thanks to MM)

> Snippets
> from the "readme.txt":
> 
>     An ASCII encoded file crypto application by Douglas Eagleson
>     ...
>     A modified DES Implementation, NIST: FIPS PUB 46-2, 1993-
>     The S-box relation was removed making it a complete shuffle.

Oh dear.

Cheers,

-j

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | sci.crypt

csiph-web