First draft after proof-reading by dg-latacora · Pull Request #412 · crypto101/book

dg-latacora · 2021-02-05T21:19:25Z

I still need to read over this one more time

lvh · 2021-02-06T21:11:24Z

src/stream-ciphers.rst

The original let's say appears correct?

lvh · 2021-02-06T23:07:37Z

src/stream-ciphers.rst

Hm, this is a little funky. Let's replace

Also, do not roll your own cryptosystems. In a secure system, records of Alice and Mallory probably are not encrypted using the same key.

As we'll see later on in the book, just having unpredictable IVs doesn't make a system safe! This is a general argument against rolling your own cryptosystems: a high-quality implementation might have encrypted those records under different keys. Or it could use other controls, like relying on the associated data of an AEAD (which we'll see later) to make sure processes wouldn't perform cryptographic operations on behalf of Mallory that would also have worked for Alice.

Thanks! This is great. I will make the changes

I have a question on original wording.

In " In a secure system, records of Alice and Mallory probably are not encrypted using the same key.", is there any "secure" system that encrypts different entities with a same key?

lvh · 2021-02-06T23:08:55Z

src/stream-ciphers.rst

Many -> Some

lvh · 2021-02-06T23:09:11Z

src/stream-ciphers.rst

"as" feels weird here: "because" maybe?

lvh · 2021-02-06T23:09:33Z

src/stream-ciphers.rst

+Many CBC systems set the key as the :term:`initialization vector`. This seems like
+a good idea as you always need a shared secret key. It
+yields a nice performance benefit because the sender and receiver
+do not have to communicate to the IV explicitly. They already know the key


"to communicate to the IV" makes no sense; the IV is the object of the communication.

How about changing from

It yields a nice performance benefit because the sender and receiver do not have to communicate to the IV explicitly.

to

It yields a nice performance benefit because the sender and receiver do not have to exchange the IV explicitly.

lvh · 2021-02-06T23:10:02Z

src/stream-ciphers.rst

Again original reads better to me, how about you?

As a native Korean speaker, it is really difficult dealing with an article (in grammar sense). Korean doesn't have articles.

Long story short, reverted :)

lvh · 2021-02-06T23:10:21Z

src/stream-ciphers.rst

"... could just predict the key directly."

lvh · 2021-02-06T23:11:35Z

src/stream-ciphers.rst

+Lesson learned: do not use the key as an IV. Part of the fallacy in the
+introduction is assuming secret data can be in the IV given
+it only has to be unpredictable. This is not true: “secret” is
+just a different requirement from “not secret”. It does not mean a


"It does not mean a stronger one" makes no sense to me.

This is a seoncd "Lesson learned" for attack on CBC mode.

I think this whole paragraph can be reworked a bit. Maybe this can be shortened and just reiterate the importance of picking random, unpredictable IVs.

And add in a general good guide on how to generate random, unpredictable IVs? (I don't know giving a guide is a thing for this book though)

lvh · 2021-02-06T23:12:11Z

src/stream-ciphers.rst

Again this new paragraph is overall worse than the original IMO

dg-latacora · 2021-02-12T15:26:57Z

src/stream-ciphers.rst

+sake, lets say there is only one ciphertext block. This means Alice's
 ciphertext consists of an IV and one ciphertext block.

 Mallory can still try to use the application as a normal user, meaning


@lvh ,
Line 356 ends with "or ..."
Should this be updated?

That's intentional, but you could certainly just replace that with a ..

I'll leave it as the original version.

dg-latacora · 2021-02-12T15:39:05Z

src/stream-ciphers.rst

Thanks! This is great. I will make the changes

I have a question on original wording.

In " In a secure system, records of Alice and Mallory probably are not encrypted using the same key.", is there any "secure" system that encrypts different entities with a same key?

dg-latacora · 2021-02-12T15:41:47Z

src/stream-ciphers.rst

dg-latacora · 2021-02-12T15:44:21Z

src/stream-ciphers.rst

dg-latacora · 2021-02-12T15:46:38Z

src/stream-ciphers.rst

+Many CBC systems set the key as the :term:`initialization vector`. This seems like
+a good idea as you always need a shared secret key. It
+yields a nice performance benefit because the sender and receiver
+do not have to communicate to the IV explicitly. They already know the key


How about changing from

It yields a nice performance benefit because the sender and receiver do not have to communicate to the IV explicitly.

to

It yields a nice performance benefit because the sender and receiver do not have to exchange the IV explicitly.

dg-latacora · 2021-02-12T15:47:36Z

src/stream-ciphers.rst

dg-latacora · 2021-02-12T15:50:38Z

src/stream-ciphers.rst

As a native Korean speaker, it is really difficult dealing with an article (in grammar sense). Korean doesn't have articles.

Long story short, reverted :)

dg-latacora · 2021-02-12T16:22:15Z

src/stream-ciphers.rst

dg-latacora · 2021-02-12T16:26:41Z

src/stream-ciphers.rst

First draft after proof-reading

a61ec44

lvh reviewed Feb 6, 2021

View reviewed changes

dg-latacora commented Feb 12, 2021

View reviewed changes

Updated per lvh's suggestions

2204796

lvh approved these changes Feb 12, 2021

View reviewed changes

Conversation

dg-latacora commented Feb 5, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Comments