Fw: isn't this the worst possible report?? -- i went back and put a copy on a memstick; see attachment

[Jules Gilbert]

See attachment,  Simple program, in C.  Without access to  a file, it "partially characterizes" it.  (My term for weakly predicting it.)  Why is this useful?, read on.
But please help me.  These attacks are limiting my work efforts.

     
----- Forwarded Message -----
 From: Jules Gilbert <repeatable_compression at yahoo.com>
 To: Julian Elischer <julian at freebsd.org> 
 Sent: Thursday, October 6, 2016 2:07 AM
 Subject: Re: isn't this the worst possible report?? -- i went back and put a copy on a memstick; see attachment
   
First, the machine wasn't new, it's more than five years old.  Sorry, I thought my post was obvious, that the OS environment was brand-new.  Sorry to confuse you.
Second, I've been getting hit everyday, everytime I put up a non-CDROM based OS.     No matter the day, no matter the time, (which makes me think it's not one person.)
And why am I in this situation?
Well, not that I know the reason,  but I actually do have repeatable compression, except lot's of folks don't believe me.

Some in the FreeBSD community have my give-away demo.  What I describe is available, it's in C and not difficult for any programmer to follow.   (And, except for the usual fopen/fgetc/similar, the program contains no API references.)   I'm running off a CD, so I don't have it on the disk (how do I mount the underlying disk?  I'm running Lubuntu, it's the disk I had on hand.)  My point, if you ask I'll send you a copy.

About my demo;  it serves two purposes.
SCENARIO #1:   You are on machine 1, you want a file from machine 2.    This is without wires, wireless, media transfer, it's all done by guessing, nothing else.  Lot's of people think it's right 50% of the time, not so.  It's right (this version,) 75% of the time.

You have the system PRNG (a random-number generator that is restartable;  Both the SEND and RCVE machines must use the same key-seed.  How about 1.0?
It guesses 'p', where:
int p = r >= d;
(The function that does this is called "rdRELATION" in the code, it returns a one or zero.)  

Without knowing or having any access to 'd'.  The demo version is right with a probability of 0.75 (that's 75%.)  The commercial version is correct with a probability of 1.
Now if you know 'p', then you can do a lot to infer 'd'.  You can iterate, XOR'ing 'r' through a sequence of values.  Let me not detail the works but instead just say that deriving 'd' is easy.
Again, to those people who work on FreeBSD, ask and I'll send you a copy.   (I just spent a few minutes putting a copy on a memstick and attaching it.)

Okay, now it get's deep...
SCENARIO #2:    Basically, the same problem, except now the file containing the 'd' vector of values doesn't exist.   That file won't exist for a week, which is when you'll sit down and write the message to yourself.

When you're done laughing...
Except we (we geeks,) already do something very similar to this.    I'm not kidding.




      From: Julian Elischer <julian at freebsd.org>
 To: freebsd-security at freebsd.org 
 Sent: Wednesday, October 5, 2016 7:14 PM
 Subject: Re: isn't this the worst possible report??
  
On 5/10/2016 7:21 AM, Jules Gilbert via freebsd-security wrote:
> Well maybe worse, that the deal with AT&T for the BSD franchise has fallen apart...
> Okay, so I have a FreeBSD 10.1 CD-ROM,  believed to be a true copy and authentic copy.
> And I loaded it on a computer.  I did this entirely offline.  I also supplied passwords.
>
> Then I went online to get packages.
> Nothing unusual happened UNTIL the machine seized and when I rebooted I discovered it would hang and reboot.  A loop.
> I had done nothing to cause this.  I had not opened an X session nor done anything other than load packages such as maxima, cproto.  Nothing involved in the area of security.
>
> I had thought this was pretty much impossible...  Remember, this machine was brand new, I'd loaded FBSD-10.1 on it no more than an hour prior and had not messed with any of the internals.
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
>
>
depending on where it rebooted, it really sounds like an infant 
mortality problem..  (failure in computer or drive).

(brand new machines have a much higher chance of failure than middle 
aged machines, as all the components burn in.)

why is this in 'security'?




_______________________________________________
freebsd-security at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"