[Ape Gone Insane]

(Original post by hassi94)
Engineer edible apples that actually grow to look like the apple logo, and then distribute them to major supermarkets.

Or you can just, you know, take a bite out of a normal apple and get the same result.

[Mad Vlad]

(Original post by Gofre)
Apple are holding a conference call today to announce what they plan to do with their $100billion cash reserves, could make for some interesting reading later

PHB style... hire a consultant.

[Mad Vlad]

(Original post by Ape Gone Insane)
Or you can just, you know, take a bite out of a normal apple and get the same result.

Nah, it'd go all brown. Wouldn't be on brand...

[Intriguing Alias]

(Original post by Ape Gone Insane)
Or you can just, you know, take a bite out of a normal apple and get the same result.

Wouldn't have the same effect.. Plus it needs to be silver (without artificial colours ).

(Original post by Vulpes)
Can't be too difficult right? All you have to do is force the apples to grow into that shape by surrounding it with a small, shaped metal box. Similar to how they make square watermelons in Japan.

I don't know the logistics but watermelons are a lot more just.. water so growth is probably more malleable

[Dez]

(Original post by Kenny_uk)
I have a number ideas for that. either there is an override kept of site in a secure location with extremely limited access to it. so if the USB key is lost, a person from the company has to come out with override, and register the new key for use with that drive.
^ that's the more secure/high level version
Otherwise, I could provide a method where the company has two copies of the key. So if one is lost, the second can be delivered. however there can only ever be two keys to every drive. No more. if the organisation loses the second and doesn't have a backup, then they lose access. that simple.

The box is designed to prevent tampering and prevent access, possibly destroying data inside of the drive is improperly accessed.

Interesting. You'd need some kind of embedded system I think, the HDD itself could not act as both a USB client (to the PC) and as a USB host (to the key). If you stuck a Rasberry Pi or something inside it, then hook it directly to the HDD, you could then control access using the USB key, which contains the passphrase file to the encrypted drive.

This wouldn't stop someone from copying the key itself though. But since the USB key is writable you could do what most keycard systems do and have a one-in, one-out system. That means if someone does duplicate the key, and then uses it, the original key gets voided and can no longer be used. Similarly if someone makes a key clone, then the original is used, the clone would be nulled instead.

It's certainly an interesting project. Is it a school/uni thing, or just something you dreamt up?

[Kenny_uk]

(Original post by Dez)
Interesting. You'd need some kind of embedded system I think, the HDD itself could not act as both a USB client (to the PC) and as a USB host (to the key). If you stuck a Rasberry Pi or something inside it, then hook it directly to the HDD, you could then control access using the USB key, which contains the passphrase file to the encrypted drive.

This wouldn't stop someone from copying the key itself though. But since the USB key is writable you could do what most keycard systems do and have a one-in, one-out system. That means if someone does duplicate the key, and then uses it, the original key gets voided and can no longer be used. Similarly if someone makes a key clone, then the original is used, the clone would be nulled instead.

It's certainly an interesting project. Is it a school/uni thing, or just something you dreamt up?

My own idea, thought it could be a viable commercial idea

[Chrosson]

(Original post by Mad Vlad)
I think what S-Man was possibly alluding to was if the WAN connection was on the blink, then how could you get around that problem with a VPN connection, which traverses the same WAN.

To be perfectly honest, I have no idea. No details were given.
It might have been something to do with the DNS dying, which would explain it (but doesn't explain why the dns cache didn't help).

[Kenny_uk]

(Original post by Dez)
Interesting. You'd need some kind of embedded system I think, the HDD itself could not act as both a USB client (to the PC) and as a USB host (to the key). If you stuck a Rasberry Pi or something inside it, then hook it directly to the HDD, you could then control access using the USB key, which contains the passphrase file to the encrypted drive.

This wouldn't stop someone from copying the key itself though. But since the USB key is writable you could do what most keycard systems do and have a one-in, one-out system. That means if someone does duplicate the key, and then uses it, the original key gets voided and can no longer be used. Similarly if someone makes a key clone, then the original is used, the clone would be nulled instead.

It's certainly an interesting project. Is it a school/uni thing, or just something you dreamt up?

Also, I just realised how rude my last reply sounded, sorry I'd just woken up lol.

I actually thought of it in the middle of a networking lecture. My lecturer had gone of on another one of his tangents, and I was considering ideas for my Dissertation in Year 3, and started toying with this idea

[ch0llima]

(Original post by Chrosson)
To be perfectly honest, I have no idea. No details were given.
It might have been something to do with the DNS dying, which would explain it (but doesn't explain why the dns cache didn't help).

It was probably a campus firewall problem, then - did you check NetSight? A VPN probably wouldn't have helped with a JaNET infrastructural outage and I've been a JaNET user for years and years with very few issues relating to JaNET itself - it's epically reliable in my experience and its infrastructure is sound.

They don't give details because a) 99.9% of the student population don't understand it, so why bother and b) the 0.1% who do it's none of their business and they should stick to their pointless Java assignments doing things that don't need doing in a way you wouldn't normally do it. These University sysadmins don't like CompSci students poking their noses in and they certainly hated us Security and Ethical Hacking crew for the **** we pulled.

But, again, what do I know?

[Chrosson]

(Original post by ch0llima)
It was probably a campus firewall problem, then - did you check NetSight? A VPN probably wouldn't have helped with a JaNET infrastructural outage and I've been a JaNET user for years and years with very few issues relating to JaNET itself - it's epically reliable in my experience and its infrastructure is sound.

I managed to dig up a two sentence summary, you are correct in that it was not JANETs fault.
I was not aware of netsight, but once I figured out the VPN trick I wasn't really bothered about digging any more. Typical end-user, if it works who cares how?

But, again, what do I know?

[Chrosson]

****in' makefiles, how do they work?

I swear, of all the misbegotten creations from the minds of Unix developers, makefiles and autotools rank as one of the worst. If trying to beat them into submission wasn't so tragic it would be hilarious.

It's like a variation of the 'Yo dawg' meme. Just in case one language for your application isn't enough, you get a completely different one to get your application to compile. But sometimes this is too inflexible, so we use configure files. But sometimes editing these by hand is too error-prone, so we generate configure files automatically. Hey guys, how many more abstraction layers can we get in there!? It's so much fun debugging the thousand lines of computer generated garbage! And (of course) you have to know all three layers of this mess to be prepared for other developers.

But then, they're 30 years old and they do have (some) good points. But they could be so much better...which is precisely why there are now alternatives like cmake and scons (and why other languages made their own build mechanisms). But then we all know de-facto doesn't mean good.

[Dez]

(Original post by Chrosson)
****in' makefiles, how do they work?

I swear, of all the misbegotten creations from the minds of Unix developers, makefiles and autotools rank as one of the worst. If trying to beat them into submission wasn't so tragic it would be hilarious.

It's like a variation of the 'Yo dawg' meme. Just in case one language for your application isn't enough, you get a completely different one to get your application to compile. But sometimes this is too inflexible, so we use configure files. But sometimes editing these by hand is too error-prone, so we generate configure files automatically. Hey guys, how many more abstraction layers can we get in there!? It's so much fun debugging the thousand lines of computer generated garbage! And (of course) you have to know all three layers of this mess to be prepared for other developers.

But then, they're 30 years old and they do have (some) good points. But they could be so much better...which is precisely why there are now alternatives like cmake and scons (and why other languages made their own build mechanisms). But then we all know de-facto doesn't mean good.

Makefiles are a nice idea at a simple level, I use them for web projects in order to combine certain tasks e.g. update, minify and deployment. But when it comes to compiled languages, well, I've heard the horror stories. Think I'm happy sticking with PHP to be perfectly honest.

[Mad Vlad]

(Original post by ch0llima)
It was probably a campus firewall problem, then - did you check NetSight? A VPN probably wouldn't have helped with a JaNET infrastructural outage and I've been a JaNET user for years and years with very few issues relating to JaNET itself - it's epically reliable in my experience and its infrastructure is sound.

They don't give details because a) 99.9% of the student population don't understand it, so why bother and b) the 0.1% who do it's none of their business and they should stick to their pointless Java assignments doing things that don't need doing in a way you wouldn't normally do it. These University sysadmins don't like CompSci students poking their noses in and they certainly hated us Security and Ethical Hacking crew for the **** we pulled.

But, again, what do I know?

Oh?

[Kenny_uk]

(Original post by Dez)
Interesting. You'd need some kind of embedded system I think, the HDD itself could not act as both a USB client (to the PC) and as a USB host (to the key). If you stuck a Rasberry Pi or something inside it, then hook it directly to the HDD, you could then control access using the USB key, which contains the passphrase file to the encrypted drive.

This wouldn't stop someone from copying the key itself though. But since the USB key is writable you could do what most keycard systems do and have a one-in, one-out system. That means if someone does duplicate the key, and then uses it, the original key gets voided and can no longer be used. Similarly if someone makes a key clone, then the original is used, the clone would be nulled instead.

It's certainly an interesting project. Is it a school/uni thing, or just something you dreamt up?

So I spoke to a guy in year two of Information Security here, who's putting alot of info into this project for me. He suggested I work on developing the idea then implement it through my project management/dissertation in years 2 and 3.
However I don't like the idea of putting something like this into my project management as I know it is not something I could develop on my own. infact, after drawing up plans and designs, I realised I'm going to need an encryption specialist, an engineer and possibly a damned good coder...

As for the USB keys. we're thinking of implementing a writeblocker so nothing can be written to the keys after the first time. one, which the user keeps hold of, has standard access and modification rights, whereas the other has ROOT rights for that box only and is stored offsite in a secure location.

[Mad Vlad]

(Original post by Kenny_uk)
So I spoke to a guy in year two of Information Security here, who's putting alot of info into this project for me. He suggested I work on developing the idea then implement it through my project management/dissertation in years 2 and 3.
However I don't like the idea of putting something like this into my project management as I know it is not something I could develop on my own. infact, after drawing up plans and designs, I realised I'm going to need an encryption specialist, an engineer and possibly a damned good coder...

As for the USB keys. we're thinking of implementing a writeblocker so nothing can be written to the keys after the first time. one, which the user keeps hold of, has standard access and modification rights, whereas the other has ROOT rights for that box only and is stored offsite in a secure location.

Dez is right; TrueCrypt can achieve this already.

You can create an encrypted volume on a USB stick that requires a password and an encryption key to access it. The encryption key is just a text file that contains a private random key, essentially creating a two-factor authentication for the file. You could store that key on another USB stick and avoid the need for additional hardware.

[Chrosson]

I think I've missed a critical post here, I feel lost.

(Original post by Dez)
This wouldn't stop someone from copying the key itself though. But since the USB key is writable you could do what most keycard systems do and have a one-in, one-out system. That means if someone does duplicate the key, and then uses it, the original key gets voided and can no longer be used. Similarly if someone makes a key clone, then the original is used, the clone would be nulled instead.

I don't understand. Are you talking about a simple USB drive with the key written to the storage?
Why would you not create USB device with specialised hardware (thereby preventing copying) to provide (say) a complete challenge-auth whatsit with a delay of 5 mins to prevent brute forcing (for example)?

(Original post by Kenny_uk)
So I spoke to a guy in year two of Information Security here, who's putting alot of info into this project for me. He suggested I work on developing the idea then implement it through my project management/dissertation in years 2 and 3.
However I don't like the idea of putting something like this into my project management as I know it is not something I could develop on my own. infact, after drawing up plans and designs, I realised I'm going to need an encryption specialist, an engineer and possibly a damned good coder...

As for the USB keys. we're thinking of implementing a writeblocker so nothing can be written to the keys after the first time. one, which the user keeps hold of, has standard access and modification rights, whereas the other has ROOT rights for that box only and is stored offsite in a secure location.

Similar to above, why limit yourself to a USB drive? Of course, I'm not privy to all the info you have at hand, so take my suggestion with a pinch of salt, but why not contain an entire (to quote an earlier post of yours) "authentication system" within the hardware of the USB device? But that does have downsides...

There were two main things I learnt in security courses
1) Security is hard.
2) Hardware security is really hard.

To quote one guy - "We teach you security so you know you can't go out there and build a secure system. However, we can sell you a product that does allow you to do this. It's called a PhD."
But then, this was a general CS course.

Good luck with it, it sounds interesting.

[Kenny_uk]

(Original post by Chrosson)
I think I've missed a critical post here, I feel lost.

I don't understand. Are you talking about a simple USB drive with the key written to the storage?
Why would you not create USB device with specialised hardware (thereby preventing copying) to provide (say) a complete challenge-auth whatsit with a delay of 5 mins to prevent brute forcing (for example)?


Similar to above, why limit yourself to a USB drive? Of course, I'm not privy to all the info you have at hand, so take my suggestion with a pinch of salt, but why not contain an entire (to quote an earlier post of yours) "authentication system" within the hardware of the USB device? But that does have downsides...

There were two main things I learnt in security courses
1) Security is hard.
2) Hardware security is really hard.

To quote one guy - "We teach you security so you know you can't go out there and build a secure system. However, we can sell you a product that does allow you to do this. It's called a PhD."
But then, this was a general CS course.

Good luck with it, it sounds interesting.

Yeah if you go back to a page or so, I've tried to outline details.
the authentication system on the USB device is what we are thinking, but we want to have it verified on the side of the actually storage device, sort of as an extra layer.

(Original post by Mad Vlad)
Dez is right; TrueCrypt can achieve this already.

You can create an encrypted volume on a USB stick that requires a password and an encryption key to access it. The encryption key is just a text file that contains a private random key, essentially creating a two-factor authentication for the file. You could store that key on another USB stick and avoid the need for additional hardware.

The thing is, we don't want this to use public software, we want to have full control over everything from the encryption, to the security.
But the idea of putting in an encrypted volume storing the key is interesting..

[Mad Vlad]

(Original post by Kenny_uk)
Yeah if you go back to a page or so, I've tried to outline details.
the authentication system on the USB device is what we are thinking, but we want to have it verified on the side of the actually storage device, sort of as an extra layer.


The thing is, we don't want this to use public software, we want to have full control over everything from the encryption, to the security.
But the idea of putting in an encrypted volume storing the key is interesting..

The problem is, strong encryption algorithms are all public. Unless you're thinking of a new encryption method, you're going to have to use a public algorithm. Proprietary encryption software/hardware is arguably no more secure than open source equivalents, as it's not the software or hardware that provides the strength of the encryption; it's the algorithm that provides the strength.

[Kenny_uk]

(Original post by Mad Vlad)
The problem is, strong encryption algorithms are all public. Unless you're thinking of a new encryption method, you're going to have to use a public algorithm. Proprietary encryption software/hardware is arguably no more secure than open source equivalents, as it's not the software or hardware that provides the strength of the encryption; it's the algorithm that provides the strength.

Oh I don't disagree, but I just want alternatives if possible, especially if I can find a system that can be embedded within another program/OS. Which i don't know if Truecrypt can be?

[ch0llima]

I think my spacebar is slowly dying. It feels different, sticks a bit and doesn't always respond - probably Starcraft rage

(Original post by Mad Vlad)
Oh?

We had our own heavily firewalled network with only port 80 open. Even then, all traffic going to core University systems (WebCT, Webmail etc.) was dropped for security reasons so we needed to use our own laptops and the campus WiFi for that.

The Cisco ASA (or maybe it was a PIX - can't quite remember) was set up to stop all traffic out of the NATted network in the event of serious security alerts against University systems e.g. port scans against central University IT infrastructure. Eventually they rolled out a new IDS policy to lock out individual workstations (we didn't have user accounts - all machines were restorable boxes running as Administrator so we could do what we wanted as long as we restored the base image afterwards) rather than the entire NAT range but it was occasionally fun to lock out the entire lab for lulz.

In short, they didn't like us because we were a lot of extra work and were the exact type of people pre-programmed to make their lives difficult. Someone else also apparently found a 0day in the main portal software.

(Original post by Chrosson)
There were two main things I learnt in security courses
1) Security is hard.
2) Hardware security is really hard.

To quote one guy - "We teach you security so you know you can't go out there and build a secure system. However, we can sell you a product that does allow you to do this. It's called a PhD."
But then, this was a general CS course.

This is nonsense and whoever told you this should jump in front of a train. You also didn't learn very much.

(Original post by Kenny_uk)
Oh I don't disagree, but I just want alternatives if possible, especially if I can find a system that can be embedded within another program/OS. Which i don't know if Truecrypt can be?

Careful with rolling your own encryption schemes, algorithms or systems. There's a reason why some of the brightest minds in the world work on that sort of stuff and how it goes through brutal peer review. TrueCrypt is the best I've seen and you can encrypt whole physical volumes with it. However, if you're truly wanting to break away from what has already been used, you're going to have to seriously think outside of the box.

I'm beginning to think that your very own hardware solution is probably the key (hurr hurr hurr) to this conundrum of Thor+Ultralisk proportions. I can't currently think of anything which would work straight out of the box, or indeed be adapted straight out of said box, so it's a hugely complex problem and one I can't really go into right now because it requires a very, very serious amount of thought.