Randall Smith wrote:
Worse case, something that looks like this would land on the disk.
crc32 checksum + translation table + malware
It would be safer to add something to both the
beginning *and* end of the file. Some file formats,
e.g. zip, pdf, are designed to be read starting
from the end
On 06/30/2015 01:33 PM, Chris Angelico wrote:
From the software's point of view, it has two distinct
modes: server, in which it listens on a socket and receives data, and
client, in which it connects to other people's sockets and sends data.
As such, the "server" mode is the only one that receiv
On Tue, 30 Jun 2015 23:25:01 +, Jon Ribbens wrote:
> On 2015-06-30, Steven D'Aprano wrote:
>> I don't think there has been much research into keeping at least *some*
>> security even when keys have been compromised, apart from as it relates
>> to two-factor authentication.
>
> That's because
On 2015-06-30, Steven D'Aprano wrote:
> I don't think there has been much research into keeping at least *some*
> security even when keys have been compromised, apart from as it relates to
> two-factor authentication.
That's because "the key" is all the secret part. If an attacker knows
the algor
On Wed, Jul 1, 2015 at 4:59 AM, Steven D'Aprano wrote:
> Today, if the key is compromised, all is lost. Is it possible that there are
> ciphers that are resistant to discovery of the key? Obviously if you know
> the key you can read encrypted messages, that's what the key is for, but
> there are s
On Wed, 1 Jul 2015 03:39 am, Randall Smith wrote:
> On 06/29/2015 10:00 PM, Steven D'Aprano wrote:
>> I'm making an assumption here -- I assume that the sender records a
>> checksum for uploaded files so that when they get something back again
>> they can tell whether or not it is the same conten
On 2015-06-30, Steven D'Aprano wrote:
> On Tue, 30 Jun 2015 10:19 pm, Jon Ribbens wrote:
>> Eh? The game is over right there. I don't trust you, and yet
>> I have just given you my private data, unencrypted.
>
> Yes. That is exactly the problem. If the application doesn't encrypt the
> data for me
On Wed, Jul 1, 2015 at 4:17 AM, Steven D'Aprano wrote:
> If you can trick me into turning encryption off (say, you use a social
> engineering attack on me and convince me to delete "the virus crypto.py"),
> then I might inadvertently upload unencrypted data to you. Or maybe you
> find an attack on
On Tue, 30 Jun 2015 10:19 pm, Jon Ribbens wrote:
> On 2015-06-30, Steven D'Aprano wrote:
>> On Tue, 30 Jun 2015 06:52 am, Randall Smith wrote:
>>> Not sure why you posted the link. The crc32 checksum is just to check
>>> for possible filesystem corruption. The system does periodic data
>>> corr
On 06/29/2015 03:49 PM, Jon Ribbens wrote:
On 2015-06-29, Randall Smith wrote:
Same reason newer filesystems like BTRFS use checkusms (BTRFS uses
CRC32). The storage machine runs periodic file integrity checks. It
has no control over the underlying filesystem.
True, but presumably neither d
On 06/29/2015 10:00 PM, Steven D'Aprano wrote:
On Tue, 30 Jun 2015 06:52 am, Randall Smith wrote:
Not sure why you posted the link. The crc32 checksum is just to check
for possible filesystem corruption. The system does periodic data
corruption checks. BTRFS uses crc32 checksums also. Pleas
On 2015-06-30, Steven D'Aprano wrote:
> On Tue, 30 Jun 2015 06:52 am, Randall Smith wrote:
>> Not sure why you posted the link. The crc32 checksum is just to check
>> for possible filesystem corruption. The system does periodic data
>> corruption checks. BTRFS uses crc32 checksums also. Please
On Tue, 30 Jun 2015 06:52 am, Randall Smith wrote:
> Not sure why you posted the link. The crc32 checksum is just to check
> for possible filesystem corruption. The system does periodic data
> corruption checks. BTRFS uses crc32 checksums also. Please explain.
The file system can trust that a
On 2015-06-29, Randall Smith wrote:
> Same reason newer filesystems like BTRFS use checkusms (BTRFS uses
> CRC32). The storage machine runs periodic file integrity checks. It
> has no control over the underlying filesystem.
True, but presumably neither does it have anything it can do to
recti
On 06/27/2015 01:50 PM, Steven D'Aprano wrote:
On Sun, 28 Jun 2015 03:08 am, Randall Smith wrote:
Though I didn't mention it in the description, the storage server is
appending a CRC32 checksum for routine integrity checks. So by the time
the data hits the disk, it will have added both a 256 b
On 06/28/2015 09:21 AM, Jon Ribbens wrote:
On 2015-06-27, Randall Smith wrote:
Thankyou. Nice points. I do think given the risks (there are always
risks) discussed, a successful attack of this nature is not very likely.
Worse case, something that looks like this would land on the disk.
crc
On Saturday 27 June 2015 08:27:38 Laura Creighton wrote:
> In a message of Sat, 27 Jun 2015 20:16:47 +1000, Chris Angelico writes:
> >Okay, Johannes, NOW you're proving that you don't have a clue what
> >you're talking about. D-K effect doesn't go away...
> >
> >ChrisA
>
> You need to read the pa
On 2015-06-27, Randall Smith wrote:
> Thankyou. Nice points. I do think given the risks (there are always
> risks) discussed, a successful attack of this nature is not very likely.
> Worse case, something that looks like this would land on the disk.
>
> crc32 checksum + translation table + ma
On 2015-06-27, Steven D'Aprano wrote:
> Despite his initial claim that he doesn't want to use AES because it's too
> slow implemented as pure Python, Randall has said that the application will
> offer AES encryption as an option. (He says it is enabled by default,
> except that the user can turn i
On Sat, Jun 27, 2015 at 6:18 PM, Steven D'Aprano wrote:
> On Sun, 28 Jun 2015 06:30 am, Devin Jeanpierre wrote:
>
>> On Fri, Jun 26, 2015 at 11:16 PM, Steven D'Aprano
>> wrote:
>>> On Sat, 27 Jun 2015 02:05 pm, Devin Jeanpierre wrote:
>>>
On Fri, Jun 26, 2015 at 8:38 PM, Steven D'Aprano
>>>
On Sun, 28 Jun 2015 06:30 am, Devin Jeanpierre wrote:
> On Fri, Jun 26, 2015 at 11:16 PM, Steven D'Aprano
> wrote:
>> On Sat, 27 Jun 2015 02:05 pm, Devin Jeanpierre wrote:
>>
>>> On Fri, Jun 26, 2015 at 8:38 PM, Steven D'Aprano
>>> wrote:
Now you say that the application encrypts the data,
On Sun, Jun 28, 2015 at 4:51 AM, Steven D'Aprano wrote:
> On Sun, 28 Jun 2015 04:22 am, Randall Smith wrote:
>
>> The owner (client software) encrypts the data using AES. This is the
>> default behavior of the client software. If the client chooses to
>> disable encryption, that's their issue fo
On Fri, Jun 26, 2015 at 11:16 PM, Steven D'Aprano wrote:
> On Sat, 27 Jun 2015 02:05 pm, Devin Jeanpierre wrote:
>
>> On Fri, Jun 26, 2015 at 8:38 PM, Steven D'Aprano
>> wrote:
>>> Now you say that the application encrypts the data, except that the user
>>> can turn that option off.
>>>
>>> Just
On Sat, Jun 27, 2015 at 11:35 AM, Steven D'Aprano wrote:
> On Sun, 28 Jun 2015 01:09 am, Ian Kelly wrote:
>
>> On Sat, Jun 27, 2015 at 2:38 AM, Steven D'Aprano
>> wrote:
>>> Can you [generic you] believe that attackers can *reliably* attack remote
>>> systems based on a 20µs timing differences? I
On Sun, 28 Jun 2015 04:22 am, Randall Smith wrote:
> The owner (client software) encrypts the data using AES. This is the
> default behavior of the client software. If the client chooses to
> disable encryption, that's their issue for sure.
I cannot imagine what you think you gain from allowing
On Sun, 28 Jun 2015 03:08 am, Randall Smith wrote:
> Though I didn't mention it in the description, the storage server is
> appending a CRC32 checksum for routine integrity checks. So by the time
> the data hits the disk, it will have added both a 256 byte translation
> table and a 4 byte checksu
On Jun 27, 2015 11:51 AM, "Paul Rubin" wrote:
>
> Michael Torrie writes:
> > Furthermore you cannot prove a negative, which is what proving
> > security is for anything but the trivial case. Are you saying this is
> > untrue?
>
> I've always thought that there are no two even numbers that when yo
On 06/27/2015 07:38 AM, Grant Edwards wrote:
On 2015-06-26, Randall Smith wrote:
The only person who can read a file is the owner.
That's always the plan, but many a successful exploit has been based
on breaking that assumption. If privacy actually matters, that's not
a good assumption to r
On 06/27/2015 03:29 AM, Peter Otten wrote:
Would it be sufficient to prepend the chunk with one block, say, of random
data? To unmangle you'd just strip off that block.
BLOCK = os.urandom(BLOCKSIZE)
def mangle(source, dest):
dest.write(BLOCK)
shutil.copyfileobj(source, dest)
def un
On Sun, 28 Jun 2015 03:35 am, Steven D'Aprano wrote:
> On Sun, 28 Jun 2015 01:09 am, Ian Kelly wrote:
>> The time to obfuscate a single byte is constant,
>
> Are you sure about that? Bet your house? How about your computer?
Correction: the example I showed uses str, not bytes.
With bytes, the
Michael Torrie writes:
> Furthermore you cannot prove a negative, which is what proving
> security is for anything but the trivial case. Are you saying this is
> untrue?
I've always thought that there are no two even numbers that when you add
them together, give you an odd number. Are you saying
On Sun, 28 Jun 2015 01:09 am, Ian Kelly wrote:
> On Sat, Jun 27, 2015 at 2:38 AM, Steven D'Aprano
> wrote:
>> Can you [generic you] believe that attackers can *reliably* attack remote
>> systems based on a 20µs timing differences? If you say "No", then you
>> fail Security 101 and should step awa
On 06/26/2015 08:21 PM, Chris Angelico wrote:
On Sat, Jun 27, 2015 at 6:09 AM, Randall Smith wrote:
Give me one plausible scenario where an attacker can cause malware to hit
the disk after bytearray.translate with a 256 byte translation table and
I'll be thankful to you.
The entire 256-byte t
On 06/26/2015 03:11 PM, Johannes Bauer wrote:
> You misunderstand. This is now how it works, this is not how any of this
> works. Steven does not *at all* have to prove to you your system is
> breakable or show actual attacks. YOU have to prove that your system is
> secure.
Ahh the holy grail of
On Sat, Jun 27, 2015 at 2:38 AM, Steven D'Aprano wrote:
> Can you [generic you] believe that attackers can *reliably* attack remote
> systems based on a 20µs timing differences? If you say "No", then you fail
> Security 101 and should step away from the computer until a security expert
> can be ca
On Sat, Jun 27, 2015 at 5:33 AM, Chris Angelico wrote:
> On Sat, Jun 27, 2015 at 8:18 PM, Johannes Bauer wrote:
>> I've looked at your code even though I don't know pike. That's the
>> typesafe JavaScript derivative, isn't it?
>
> Not really; it's more like "Python semantics meets C++ syntax". Bu
In a message of Sat, 27 Jun 2015 15:23:07 +0300, Jussi Piitulainen writes:
>Laura Creighton writes:
>
>> Johannes, if you don't know "Yes, Minister" then you most likely do
>> not know the Politician's Syllogism (which now has its own wikipedia
>> page :) And I _didn't_ do it! Honest!)
>>
>> Some
On 2015-06-26, Randall Smith wrote:
> The only person who can read a file is the owner.
That's always the plan, but many a successful exploit has been based
on breaking that assumption. If privacy actually matters, that's not
a good assumption to rely on as a single point of failure.
--
Grant
In a message of Sat, 27 Jun 2015 20:16:47 +1000, Chris Angelico writes:
>Okay, Johannes, NOW you're proving that you don't have a clue what
>you're talking about. D-K effect doesn't go away...
>
>ChrisA
You need to read the paper again. That was the whole point -- when
Kruger and Dunning went an
Laura Creighton writes:
> Johannes, if you don't know "Yes, Minister" then you most likely do
> not know the Politician's Syllogism (which now has its own wikipedia
> page :) And I _didn't_ do it! Honest!)
>
> Something must be done.
> This is something.
> Therefore we must do it!
Surely that's
On Sat, Jun 27, 2015 at 8:18 PM, Johannes Bauer wrote:
> On 27.06.2015 11:17, Chris Angelico wrote:
>
>> Good, so this isn't like that episode of Yes Minister when they were
>> trying to figure out whether to allow a chemical factory to be built.
>
> I must admit that I have no clue about that sho
Johannes, if you don't know "Yes, Minister" then you most likely do
not know the Politician's Syllogism (which now has its own wikipedia
page :) And I _didn't_ do it! Honest!)
Something must be done.
This is something.
Therefore we must do it!
:)
Unfortunatetely, the Politician's Syllogism is
On 27.06.2015 12:16, Chris Angelico wrote:
> Okay, Johannes, NOW you're proving that you don't have a clue what
> you're talking about. D-K effect doesn't go away...
:-D
It does in some people. I've seen it happen, with knowledge comes
humility. Not saying Jon is a lost cause just yet. He's just
On 2015-06-27, Johannes Bauer wrote:
> On 27.06.2015 11:27, Jon Ribbens wrote:
>> Johannes might have all the education in the world, but he's
>> demonstrated quite comprehensively in this thread that he doesn't
>> have a clue what he's talking about.
>
> Oh, how hurtful. I might even shed a tear
On 27.06.2015 11:17, Chris Angelico wrote:
> Good, so this isn't like that episode of Yes Minister when they were
> trying to figure out whether to allow a chemical factory to be built.
I must admit that I have no clue about that show or that epsisode in
particular and needed to read up on it:
ht
On Sat, Jun 27, 2015 at 8:05 PM, Johannes Bauer wrote:
> On 27.06.2015 11:27, Jon Ribbens wrote:
>
>> Johannes might have all the education in the world, but he's
>> demonstrated quite comprehensively in this thread that he doesn't
>> have a clue what he's talking about.
>
> Oh, how hurtful. I mig
On 27.06.2015 11:27, Jon Ribbens wrote:
> Johannes might have all the education in the world, but he's
> demonstrated quite comprehensively in this thread that he doesn't
> have a clue what he's talking about.
Oh, how hurtful. I might even shed a tear or two, but it's pretty clear
to me that you'
On 2015-06-27, Chris Angelico wrote:
> On Sat, Jun 27, 2015 at 7:07 PM, Johannes Bauer wrote:
>> On 27.06.2015 10:53, Chris Angelico wrote:
>>> On Sat, Jun 27, 2015 at 6:38 PM, Steven D'Aprano
>>> wrote:
I'm not a security expert. I'm not even a talented amateur. *Every time* I
sugges
On 2015-06-27, Ian Kelly wrote:
> On Fri, Jun 26, 2015 at 7:21 PM, Chris Angelico wrote:
>> On Sat, Jun 27, 2015 at 6:09 AM, Randall Smith wrote:
>>> Give me one plausible scenario where an attacker can cause malware to hit
>>> the disk after bytearray.translate with a 256 byte translation table
On Sat, Jun 27, 2015 at 7:07 PM, Johannes Bauer wrote:
> On 27.06.2015 10:53, Chris Angelico wrote:
>> On Sat, Jun 27, 2015 at 6:38 PM, Steven D'Aprano wrote:
>>> I'm not a security expert. I'm not even a talented amateur. *Every time* I
>>> suggest that "X is secure", the security guy at work sh
On 27.06.2015 10:38, Steven D'Aprano wrote:
> Can you say "timing attack"?
>
> http://codahale.com/a-lesson-in-timing-attacks/
>
> Can you [generic you] believe that attackers can *reliably* attack remote
> systems based on a 20µs timing differences? If you say "No", then you fail
> Security 101
On 27.06.2015 10:53, Chris Angelico wrote:
> On Sat, Jun 27, 2015 at 6:38 PM, Steven D'Aprano wrote:
>> I'm not a security expert. I'm not even a talented amateur. *Every time* I
>> suggest that "X is secure", the security guy at work shoots me down in
>> flames. But nicely, because I pay his wage
On Sat, Jun 27, 2015 at 6:38 PM, Steven D'Aprano wrote:
> I'm not a security expert. I'm not even a talented amateur. *Every time* I
> suggest that "X is secure", the security guy at work shoots me down in
> flames. But nicely, because I pay his wages
Just out of interest, is _anybody_ active in
On Sat, 27 Jun 2015 03:47 pm, Ian Kelly wrote:
[...]
>> Just make the AES encryption mandatory, not optional. Then the user
>> cannot upload unencrypted malicious data, and the receiver cannot read
>> the data. That's two problems solved.
>
> And what if somebody else writes a competing version o
Randall Smith wrote:
> Chunks of data (about 2MB) are to be stored on machines using a
> peer-to-peer protocol. The recipient of these chunks can't assume that
> the payload is benign. While the data senders are supposed to encrypt
> data, that's not guaranteed, and I'd like to protect the recip
On 2015-06-27 08:58, Robert Kern wrote:
On 2015-06-27 04:38, Steven D'Aprano wrote:
Maybe you use Python's standard library and the Mersenne Twister. The period
of that is huge, possibly bigger than 256! (or not, I forget, and I'm too
lazy to look it up). So you think that's safe. But it's not:
On 2015-06-27 04:38, Steven D'Aprano wrote:
Maybe you use Python's standard library and the Mersenne Twister. The period
of that is huge, possibly bigger than 256! (or not, I forget, and I'm too
lazy to look it up). So you think that's safe. But it's not: Mersenne
Twister is not a cryptographica
On Sat, Jun 27, 2015 at 3:59 PM, Ian Kelly wrote:
> On Fri, Jun 26, 2015 at 7:21 PM, Chris Angelico wrote:
>> On Sat, Jun 27, 2015 at 6:09 AM, Randall Smith wrote:
>>> Give me one plausible scenario where an attacker can cause malware to hit
>>> the disk after bytearray.translate with a 256 byte
On Sat, 27 Jun 2015 02:05 pm, Devin Jeanpierre wrote:
> On Fri, Jun 26, 2015 at 8:38 PM, Steven D'Aprano
> wrote:
>> Now you say that the application encrypts the data, except that the user
>> can turn that option off.
>>
>> Just make the AES encryption mandatory, not optional. Then the user
>> c
On Fri, Jun 26, 2015 at 7:21 PM, Chris Angelico wrote:
> On Sat, Jun 27, 2015 at 6:09 AM, Randall Smith wrote:
>> Give me one plausible scenario where an attacker can cause malware to hit
>> the disk after bytearray.translate with a 256 byte translation table and
>> I'll be thankful to you.
>
> T
On Fri, Jun 26, 2015 at 9:38 PM, Steven D'Aprano wrote:
> With respect Randall, you contradict yourself. Is there any wonder that some
> of us (well, me at least) is suspicious and confused, when your story
> changes as often as the weather?
>
> Sometimes you say that the client software uses AES
On 27.06.2015 02:55, Randall Smith wrote:
> No the attacker does not have access to the ciphertext. What would lead
> you to think they did?
Years of practical experience in the field of applied cryptography.
Knowledge of how side channels work and how easily they can be
constructed for bad sche
On Fri, Jun 26, 2015 at 8:38 PM, Steven D'Aprano wrote:
> Now you say that the application encrypts the data, except that the user can
> turn that option off.
>
> Just make the AES encryption mandatory, not optional. Then the user cannot
> upload unencrypted malicious data, and the receiver cannot
On Sat, 27 Jun 2015 06:09 am, Randall Smith wrote:
> On 06/26/2015 12:06 PM, Steven D'Aprano wrote:
>> On Fri, 26 Jun 2015 11:01 am, Ian Kelly wrote:
>>
>>> You're making the same mistake that Steven did in misunderstanding the
>>> threat model.
>>
>> I don't think I'm misunderstanding the threat,
On Sat, Jun 27, 2015 at 6:09 AM, Randall Smith wrote:
> Give me one plausible scenario where an attacker can cause malware to hit
> the disk after bytearray.translate with a 256 byte translation table and
> I'll be thankful to you.
The entire 256-byte translation table is significant ONLY if you
On 06/26/2015 05:42 PM, Johannes Bauer wrote:
On 26.06.2015 23:29, Jon Ribbens wrote:
While you seem to think that Steven is rampaging about nothing, he does
have a fair point: You consistently were vague about wheter you want to
have encryption, authentication or obfuscation of data. This sugg
On 2015-06-26, Johannes Bauer wrote:
> On 26.06.2015 23:29, Jon Ribbens wrote:
>>> While you seem to think that Steven is rampaging about nothing, he does
>>> have a fair point: You consistently were vague about wheter you want to
>>> have encryption, authentication or obfuscation of data. This su
On 06/26/2015 04:07 PM, Johannes Bauer wrote:
You consistently were vague about wheter you want to
have encryption, authentication or obfuscation of data.
I knew (possibly extra) encryption wasn't necessary at this stage, but I
also knew that encryption would provide good obfuscation. Problem
On 06/26/2015 04:55 PM, Mark Lawrence wrote:
To be perfectly blunt I gave up days ago trying to follow what was being
said, just too many words from all angles and too few diagrams for me to
follow. I sincerely hope it doesn't end in tears.
Mark.
There's not much to follow. The solution w
Johannes, I agree with a lot of what you say, but can you please have
less of a mean attitude?
-- Devin
On Fri, Jun 26, 2015 at 3:42 PM, Johannes Bauer wrote:
> On 26.06.2015 23:29, Jon Ribbens wrote:
>
>>> While you seem to think that Steven is rampaging about nothing, he does
>>> have a fair p
On 26.06.2015 23:29, Jon Ribbens wrote:
>> While you seem to think that Steven is rampaging about nothing, he does
>> have a fair point: You consistently were vague about wheter you want to
>> have encryption, authentication or obfuscation of data. This suggests
>> that you may not be so sure your
On Fri, Jun 26, 2015 at 3:07 PM, Johannes Bauer wrote:
> That people in 2015 actually defend inventing a substitution-cipher
> "crypto"system sends literally shivers down my spine.
I think that the people defending this have been reasonably consistent
about using the word "obfuscation", not "cryp
On 26/06/2015 22:29, Jon Ribbens wrote:
On 2015-06-26, Johannes Bauer wrote:
On 26.06.2015 22:09, Randall Smith wrote:
You've gone on a rampage about nothing. My original description said
the client was supposed to encrypt the data, but you want to assume the
opposite for some unknown reason.
On 2015-06-26, Johannes Bauer wrote:
> On 26.06.2015 22:09, Randall Smith wrote:
>> You've gone on a rampage about nothing. My original description said
>> the client was supposed to encrypt the data, but you want to assume the
>> opposite for some unknown reason.
>
> While you seem to think that
On 26.06.2015 22:09, Randall Smith wrote:
> And that's why we're having this discussion. Do you know of an attack
> in which you can control the output (say at least 100 consecutive bytes)
> for data which goes through a 256 byte translation table, chosen
> randomly from 256! permutations after t
On 26.06.2015 22:09, Randall Smith wrote:
> You've gone on a rampage about nothing. My original description said
> the client was supposed to encrypt the data, but you want to assume the
> opposite for some unknown reason.
While you seem to think that Steven is rampaging about nothing, he does
h
On 06/26/2015 12:06 PM, Steven D'Aprano wrote:
On Fri, 26 Jun 2015 11:01 am, Ian Kelly wrote:
You're making the same mistake that Steven did in misunderstanding the
threat model.
I don't think I'm misunderstanding the threat, I think I'm pointing out a
threat which the OP is hoping to just ig
On Fri, 26 Jun 2015 11:01 am, Ian Kelly wrote:
> You're making the same mistake that Steven did in misunderstanding the
> threat model.
I don't think I'm misunderstanding the threat, I think I'm pointing out a
threat which the OP is hoping to just ignore.
In an earlier post, I suggested that the
On 2015-06-26, Chris Angelico wrote:
> On Fri, Jun 26, 2015 at 1:26 AM, Jon Ribbens
> wrote:
>> Well, it means you need to send 256 times as much data, which is a
>> start. If you're instead using a 256-byte translation table then
>> an attack becomes utterly impractical.
>
> Utterly impractical?
On Fri, Jun 26, 2015 at 12:24 PM, Mark Lawrence wrote:
> On 26/06/2015 03:06, Chris Angelico wrote:
>>
>> On Fri, Jun 26, 2015 at 11:17 AM, Mark Lawrence
>> wrote:
Even the famous Enigma
machine was a lot more than just letter-for-letter substitution - a
double letter in the c
On 26/06/2015 03:06, Chris Angelico wrote:
On Fri, Jun 26, 2015 at 11:17 AM, Mark Lawrence wrote:
Even the famous Enigma
machine was a lot more than just letter-for-letter substitution - a
double letter in the cleartext wouldn't be represented by a double
letter in the result - and once the mac
On Fri, Jun 26, 2015 at 11:01 AM, Ian Kelly wrote:
> On Thu, Jun 25, 2015 at 6:33 PM, Chris Angelico wrote:
>> On Fri, Jun 26, 2015 at 1:26 AM, Jon Ribbens
>> wrote:
>>> Well, it means you need to send 256 times as much data, which is a
>>> start. If you're instead using a 256-byte translation t
On Fri, Jun 26, 2015 at 11:17 AM, Mark Lawrence wrote:
>> Even the famous Enigma
>> machine was a lot more than just letter-for-letter substitution - a
>> double letter in the cleartext wouldn't be represented by a double
>> letter in the result - and once the machine's secrets were figured
>> out
On 26/06/2015 01:33, Chris Angelico wrote:
On Fri, Jun 26, 2015 at 1:26 AM, Jon Ribbens
wrote:
There are only 256 possible values for n, one of which doesn't transform the
data at all (ROT-0). If you're thinking of attacking this by pencil and
paper, 255 transformations sounds like a lot. For a
On Thu, Jun 25, 2015 at 6:33 PM, Chris Angelico wrote:
> On Fri, Jun 26, 2015 at 1:26 AM, Jon Ribbens
> wrote:
>>> There are only 256 possible values for n, one of which doesn't transform the
>>> data at all (ROT-0). If you're thinking of attacking this by pencil and
>>> paper, 255 transformation
On Fri, Jun 26, 2015 at 1:26 AM, Jon Ribbens
wrote:
>> There are only 256 possible values for n, one of which doesn't transform the
>> data at all (ROT-0). If you're thinking of attacking this by pencil and
>> paper, 255 transformations sounds like a lot. For a computer, that's barely
>> harder th
On 06/24/2015 08:33 PM, Dennis Lee Bieber wrote:
On Wed, 24 Jun 2015 13:20:07 -0500, Randall Smith
declaimed the following:
On 06/24/2015 06:36 AM, Steven D'Aprano wrote:
I don't understand how mangling the data is supposed to protect the
recipient. Don't they have the ability unmangle the da
On 06/24/2015 11:27 PM, Devin Jeanpierre wrote:
On Wed, Jun 24, 2015 at 9:07 PM, Steven D'Aprano wrote:
But just sticking to the three above, the first one is partially mitigated
by allowing virus scanners to scan the data, but that implies that the
owner of the storage machine can spy on the f
Thanks Jon. I couldn't have answered those questions better myself, and
I wrote the software in question.
I didn't intend to describe the entire system, but rather just enough of
it to present the issue at hand. You seem to understand it quite well.
I'm now using a randomly generated 256 by
On 2015-06-25, Steven D'Aprano wrote:
> On Thu, 25 Jun 2015 08:03 pm, Jon Ribbens wrote:
>> That won't stop virus scanners etc potentially making their own minds
>> up about the file.
>
> *shrug* Sure, but I was specifically referring to the risk of the malware
> being executed, not being detected
On Thu, 25 Jun 2015 08:03 pm, Jon Ribbens wrote:
> On 2015-06-25, Steven D'Aprano
> wrote:
>> On Thursday 25 June 2015 14:27, Devin Jeanpierre wrote:
>>> If it's encrypted malware, and you can't decrypt it, there's no threat.
>>
>> If the *only* threat is that the sender will send malware, you ca
On Thu, Jun 25, 2015 at 2:57 AM, Chris Angelico wrote:
> On Thu, Jun 25, 2015 at 7:41 PM, Devin Jeanpierre
> wrote:
>>> I know that the OP doesn't propose using ROT-13, but a classical
>>> substitution cipher isn't that much stronger.
>>
>> Yes, it is. It requires the attacker being able to see s
Personally, i have had AVG give at least 2 false positives (fyi one of
them was like python2.6)
as long as antivirus software can give so many false positives i would
thing preventing your AV from nuking someone elses data is a
reasonable thing.
--
https://mail.python.org/mailman/listinfo/python-
On 2015-06-25, Steven D'Aprano wrote:
> On Thursday 25 June 2015 14:27, Devin Jeanpierre wrote:
>> If it's encrypted malware, and you can't decrypt it, there's no threat.
>
> If the *only* threat is that the sender will send malware, you can mitigate
> around that by dropping the file in an unenc
On Thu, Jun 25, 2015 at 7:41 PM, Devin Jeanpierre
wrote:
>> I know that the OP doesn't propose using ROT-13, but a classical
>> substitution cipher isn't that much stronger.
>
> Yes, it is. It requires the attacker being able to see something about
> the ciphertext, unlike ROT13. But it is reasona
On Thu, Jun 25, 2015 at 2:25 AM, Steven D'Aprano
wrote:
> On Thursday 25 June 2015 14:27, Devin Jeanpierre wrote:
>> The original post said that the sender will usually send files they
>> encrypted, unless they are malicious. So if the sender wants them to
>> be encrypted, they already are.
>
> Th
On Thursday 25 June 2015 14:27, Devin Jeanpierre wrote:
> On Wed, Jun 24, 2015 at 9:07 PM, Steven D'Aprano
> wrote:
>> But just sticking to the three above, the first one is partially
>> mitigated by allowing virus scanners to scan the data, but that implies
>> that the owner of the storage machi
On Thursday 25 June 2015 14:07, Steven D'Aprano wrote:
>> You got it. I didn't want to explain any more than necessary. But yes,
>> the recipient just stores the data for the end-user.
>
> Trust me. That's not all they are doing.
Hmm, sorry, that's a glib answer.
What I meant to say is, you c
On Wed, Jun 24, 2015 at 9:07 PM, Steven D'Aprano wrote:
> But just sticking to the three above, the first one is partially mitigated
> by allowing virus scanners to scan the data, but that implies that the
> owner of the storage machine can spy on the files. So you have a conflict
> here.
If it's
On Thu, 25 Jun 2015 04:36 am, Randall Smith wrote:
> On 06/24/2015 07:19 AM, Dennis Lee Bieber wrote:
>
>
>> Pardon, but that description has me confused. Perhaps I just don't
>> understand the full use-case.
>>
>> Who exactly is supposed to be protected from what? You state "data
>> senders are
1 - 100 of 118 matches
Mail list logo
