You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Максим Степачёв <ma...@gmail.com> on 2019/01/31 10:11:25 UTC
Does KeystoreEncryptionSpi have problem with size calculation?
Hi, I have been trying to solve a problem with calculation size for
encryption mode, it's ticket IGNITE-11129. But I found an additional place
for wrong behavior. I'm confused, Is it fine or wrong? Look at
*KeystoreEncryptionSpi#encryptedSize*, the result calculation works as
(dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
But we don't have a guarantee that dataSize is multiple of BLOCK_SZ.
Should we use this code:
((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
If yes, I'll fix it.
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Maxim.
> This record type doesn't encrypt, does it?
DataRecord includes collection of DataEntry.
DataEntry that belongs to encrypte cache is encrypted.
Please, take a look at
RecordDataV1Serializer#putEncryptedDataEntry
пт, 1 февр. 2019 г. в 12:54, Максим Степачёв <ma...@gmail.com>:
> Nikolay,
> Could you help again? I looked at the WalRecordCacheGroupAware, and found
> that the DataRecord doesn't implement it.
> This record type doesn't encrypt, does it? Is it a problem?
>
> чт, 31 янв. 2019 г. в 18:23, Максим Степачёв <ma...@gmail.com>:
>
>> Nikolay,
>> It's my mistake. You're right.
>> Thanks for answering.
>>
>> чт, 31 янв. 2019 г. в 17:50, Nikolay Izhikov <ni...@apache.org>:
>>
>>> Maxim,
>>>
>>> > I suppose the AES algorithm work with blocks by 16 bytes for encryption
>>> data + 2 bytes for padding in AES_WITH_PADDING mode
>>>
>>> Why do you make this conclusion?
>>>
>>> Actually, in AES_WITH_PADDING mode we should add 2 more *BLOCK*: for IV
>>> and
>>> for padding info.
>>> You can find sanity check in KeystoreEncryptionSpiSelfTest.
>>> Please, take a look into KeystoreEncryptionSpiSelfTest#testEncryptDecrypt
>>> which check the case you described.
>>>
>>> чт, 31 янв. 2019 г. в 17:08, Максим Степачёв <maksim.stepachev@gmail.com
>>> >:
>>> >
>>> > Nikolay,
>>> > I see. We should close IGNITE-11129 as invalid. I'm going to ask the
>>> > reporter, what he means.
>>> >
>>> > > Please, explain, why do you think so?
>>> > I answered to Dmitriy Pavlov with explaining.
>>> >
>>> > In short, your method encryptedSize(int dataSize) returns the *"*wrong
>>> > result*"* when I call it with dataSize = 20.
>>> > I suppose the AES algorithm work with blocks by 16 bytes for
>>> > encryption data + 2 bytes for padding in AES_WITH_PADDING mode.
>>> > The current implementation works for dataSize = 20: ( (20 / 16) + 2 ) *
>>> > 16. " 20 / 16 = 1." , Are we lost one block for 4 bytes? Or is it
>>> fine?
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > чт, 31 янв. 2019 г. в 16:15, Nikolay Izhikov <ni...@apache.org>:
>>> >
>>> > > Hello, Maxim.
>>> > >
>>> > > > IGNITE-11129
>>> > >
>>> > > Do we have reproducer for this ticket?
>>> > > WalRecord will be encrypted only if record class
>>> > > implements WalRecordCacheGroupAwarei.e it contains some cache data
>>> that
>>> > > should be protected with encryption.
>>> > > Please, look into private boolean needEncryption(WALRecord rec).
>>> > > SwitchSegmentRecord does not implement WalRecordCacheGroupAware, so
>>> not
>>> > > encryption would be applied for this types of records.
>>> > >
>>> > > I think we should close IGNITE-11129 as invalid.
>>> > >
>>> > > > Should we use this code:
>>> > >
>>> > > Please, explain, why do you think so?
>>> > > Do you find some bug?
>>> > > Can you send a reproducer?
>>> > >
>>> > > You can find details of encrypted data size calculation in AES
>>> algorithm
>>> > > description.
>>> > >
>>> > > чт, 31 янв. 2019 г. в 15:24, Максим Степачёв <
>>> maksim.stepachev@gmail.com
>>> >:
>>> > >
>>> > > > Dmitriy Pavlov,
>>> > > >
>>> > > > Your statement about page size is true. But our case about
>>> plainSize
>>> of
>>> > > > serialized record in bytes. This method calculates it:
>>> > > plainSize(WALRecord
>>> > > > record). For example, if you look in this method, you will see
>>> > > > DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum
>>> of: 4
>>> > > +
>>> > > > 8 + 2 + 4 + uRec.payload().length where a length is an arbitrary
>>> number.
>>> > > >
>>> > > > чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov <dp...@apache.org>:
>>> > > >
>>> > > >> Hi Maxim, why do you think that data size can be divided to cipher
>>> block
>>> > > >> size with 0 remainder.
>>> > > >>
>>> > > >> I used to think that page size 4096 is always divisible by a usual
>>> block
>>> > > >> cipher block size, e.g 32, 16 or 8 bytes
>>> > > >>
>>> > > >> чт, 31 янв. 2019 г. в 13:11, Максим Степачёв <
>>> > > maksim.stepachev@gmail.com
>>> > > >> >:
>>> > > >>
>>> > > >> > Hi, I have been trying to solve a problem with calculation size
>>> for
>>> > > >> > encryption mode, it's ticket IGNITE-11129. But I found an
>>> additional
>>> > > >> place
>>> > > >> > for wrong behavior. I'm confused, Is it fine or wrong? Look at
>>> > > >> > *KeystoreEncryptionSpi#encryptedSize*, the result calculation
>>> works as
>>> > > >> >
>>> > > >> > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
>>> > > >> >
>>> > > >> > But we don't have a guarantee that dataSize is multiple of
>>> BLOCK_SZ.
>>> > > >> > Should we use this code:
>>> > > >> >
>>> > > >> > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
>>> > > >> >
>>> > > >> > If yes, I'll fix it.
>>> > > >> >
>>> > > >>
>>> > > >
>>> > >
>>>
>>
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Posted by Максим Степачёв <ma...@gmail.com>.
Nikolay,
Could you help again? I looked at the WalRecordCacheGroupAware, and found
that the DataRecord doesn't implement it.
This record type doesn't encrypt, does it? Is it a problem?
чт, 31 янв. 2019 г. в 18:23, Максим Степачёв <ma...@gmail.com>:
> Nikolay,
> It's my mistake. You're right.
> Thanks for answering.
>
> чт, 31 янв. 2019 г. в 17:50, Nikolay Izhikov <ni...@apache.org>:
>
>> Maxim,
>>
>> > I suppose the AES algorithm work with blocks by 16 bytes for encryption
>> data + 2 bytes for padding in AES_WITH_PADDING mode
>>
>> Why do you make this conclusion?
>>
>> Actually, in AES_WITH_PADDING mode we should add 2 more *BLOCK*: for IV
>> and
>> for padding info.
>> You can find sanity check in KeystoreEncryptionSpiSelfTest.
>> Please, take a look into KeystoreEncryptionSpiSelfTest#testEncryptDecrypt
>> which check the case you described.
>>
>> чт, 31 янв. 2019 г. в 17:08, Максим Степачёв <maksim.stepachev@gmail.com
>> >:
>> >
>> > Nikolay,
>> > I see. We should close IGNITE-11129 as invalid. I'm going to ask the
>> > reporter, what he means.
>> >
>> > > Please, explain, why do you think so?
>> > I answered to Dmitriy Pavlov with explaining.
>> >
>> > In short, your method encryptedSize(int dataSize) returns the *"*wrong
>> > result*"* when I call it with dataSize = 20.
>> > I suppose the AES algorithm work with blocks by 16 bytes for
>> > encryption data + 2 bytes for padding in AES_WITH_PADDING mode.
>> > The current implementation works for dataSize = 20: ( (20 / 16) + 2 ) *
>> > 16. " 20 / 16 = 1." , Are we lost one block for 4 bytes? Or is it fine?
>> >
>> >
>> >
>> >
>> >
>> >
>> > чт, 31 янв. 2019 г. в 16:15, Nikolay Izhikov <ni...@apache.org>:
>> >
>> > > Hello, Maxim.
>> > >
>> > > > IGNITE-11129
>> > >
>> > > Do we have reproducer for this ticket?
>> > > WalRecord will be encrypted only if record class
>> > > implements WalRecordCacheGroupAwarei.e it contains some cache data
>> that
>> > > should be protected with encryption.
>> > > Please, look into private boolean needEncryption(WALRecord rec).
>> > > SwitchSegmentRecord does not implement WalRecordCacheGroupAware, so
>> not
>> > > encryption would be applied for this types of records.
>> > >
>> > > I think we should close IGNITE-11129 as invalid.
>> > >
>> > > > Should we use this code:
>> > >
>> > > Please, explain, why do you think so?
>> > > Do you find some bug?
>> > > Can you send a reproducer?
>> > >
>> > > You can find details of encrypted data size calculation in AES
>> algorithm
>> > > description.
>> > >
>> > > чт, 31 янв. 2019 г. в 15:24, Максим Степачёв <
>> maksim.stepachev@gmail.com
>> >:
>> > >
>> > > > Dmitriy Pavlov,
>> > > >
>> > > > Your statement about page size is true. But our case about plainSize
>> of
>> > > > serialized record in bytes. This method calculates it:
>> > > plainSize(WALRecord
>> > > > record). For example, if you look in this method, you will see
>> > > > DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum
>> of: 4
>> > > +
>> > > > 8 + 2 + 4 + uRec.payload().length where a length is an arbitrary
>> number.
>> > > >
>> > > > чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov <dp...@apache.org>:
>> > > >
>> > > >> Hi Maxim, why do you think that data size can be divided to cipher
>> block
>> > > >> size with 0 remainder.
>> > > >>
>> > > >> I used to think that page size 4096 is always divisible by a usual
>> block
>> > > >> cipher block size, e.g 32, 16 or 8 bytes
>> > > >>
>> > > >> чт, 31 янв. 2019 г. в 13:11, Максим Степачёв <
>> > > maksim.stepachev@gmail.com
>> > > >> >:
>> > > >>
>> > > >> > Hi, I have been trying to solve a problem with calculation size
>> for
>> > > >> > encryption mode, it's ticket IGNITE-11129. But I found an
>> additional
>> > > >> place
>> > > >> > for wrong behavior. I'm confused, Is it fine or wrong? Look at
>> > > >> > *KeystoreEncryptionSpi#encryptedSize*, the result calculation
>> works as
>> > > >> >
>> > > >> > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
>> > > >> >
>> > > >> > But we don't have a guarantee that dataSize is multiple of
>> BLOCK_SZ.
>> > > >> > Should we use this code:
>> > > >> >
>> > > >> > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
>> > > >> >
>> > > >> > If yes, I'll fix it.
>> > > >> >
>> > > >>
>> > > >
>> > >
>>
>
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Posted by Максим Степачёв <ma...@gmail.com>.
Nikolay,
It's my mistake. You're right.
Thanks for answering.
чт, 31 янв. 2019 г. в 17:50, Nikolay Izhikov <ni...@apache.org>:
> Maxim,
>
> > I suppose the AES algorithm work with blocks by 16 bytes for encryption
> data + 2 bytes for padding in AES_WITH_PADDING mode
>
> Why do you make this conclusion?
>
> Actually, in AES_WITH_PADDING mode we should add 2 more *BLOCK*: for IV and
> for padding info.
> You can find sanity check in KeystoreEncryptionSpiSelfTest.
> Please, take a look into KeystoreEncryptionSpiSelfTest#testEncryptDecrypt
> which check the case you described.
>
> чт, 31 янв. 2019 г. в 17:08, Максим Степачёв <ma...@gmail.com>:
> >
> > Nikolay,
> > I see. We should close IGNITE-11129 as invalid. I'm going to ask the
> > reporter, what he means.
> >
> > > Please, explain, why do you think so?
> > I answered to Dmitriy Pavlov with explaining.
> >
> > In short, your method encryptedSize(int dataSize) returns the *"*wrong
> > result*"* when I call it with dataSize = 20.
> > I suppose the AES algorithm work with blocks by 16 bytes for
> > encryption data + 2 bytes for padding in AES_WITH_PADDING mode.
> > The current implementation works for dataSize = 20: ( (20 / 16) + 2 ) *
> > 16. " 20 / 16 = 1." , Are we lost one block for 4 bytes? Or is it fine?
> >
> >
> >
> >
> >
> >
> > чт, 31 янв. 2019 г. в 16:15, Nikolay Izhikov <ni...@apache.org>:
> >
> > > Hello, Maxim.
> > >
> > > > IGNITE-11129
> > >
> > > Do we have reproducer for this ticket?
> > > WalRecord will be encrypted only if record class
> > > implements WalRecordCacheGroupAwarei.e it contains some cache data that
> > > should be protected with encryption.
> > > Please, look into private boolean needEncryption(WALRecord rec).
> > > SwitchSegmentRecord does not implement WalRecordCacheGroupAware, so not
> > > encryption would be applied for this types of records.
> > >
> > > I think we should close IGNITE-11129 as invalid.
> > >
> > > > Should we use this code:
> > >
> > > Please, explain, why do you think so?
> > > Do you find some bug?
> > > Can you send a reproducer?
> > >
> > > You can find details of encrypted data size calculation in AES
> algorithm
> > > description.
> > >
> > > чт, 31 янв. 2019 г. в 15:24, Максим Степачёв <
> maksim.stepachev@gmail.com
> >:
> > >
> > > > Dmitriy Pavlov,
> > > >
> > > > Your statement about page size is true. But our case about plainSize
> of
> > > > serialized record in bytes. This method calculates it:
> > > plainSize(WALRecord
> > > > record). For example, if you look in this method, you will see
> > > > DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum
> of: 4
> > > +
> > > > 8 + 2 + 4 + uRec.payload().length where a length is an arbitrary
> number.
> > > >
> > > > чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov <dp...@apache.org>:
> > > >
> > > >> Hi Maxim, why do you think that data size can be divided to cipher
> block
> > > >> size with 0 remainder.
> > > >>
> > > >> I used to think that page size 4096 is always divisible by a usual
> block
> > > >> cipher block size, e.g 32, 16 or 8 bytes
> > > >>
> > > >> чт, 31 янв. 2019 г. в 13:11, Максим Степачёв <
> > > maksim.stepachev@gmail.com
> > > >> >:
> > > >>
> > > >> > Hi, I have been trying to solve a problem with calculation size
> for
> > > >> > encryption mode, it's ticket IGNITE-11129. But I found an
> additional
> > > >> place
> > > >> > for wrong behavior. I'm confused, Is it fine or wrong? Look at
> > > >> > *KeystoreEncryptionSpi#encryptedSize*, the result calculation
> works as
> > > >> >
> > > >> > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
> > > >> >
> > > >> > But we don't have a guarantee that dataSize is multiple of
> BLOCK_SZ.
> > > >> > Should we use this code:
> > > >> >
> > > >> > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
> > > >> >
> > > >> > If yes, I'll fix it.
> > > >> >
> > > >>
> > > >
> > >
>
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Posted by Nikolay Izhikov <ni...@apache.org>.
Maxim,
> I suppose the AES algorithm work with blocks by 16 bytes for encryption
data + 2 bytes for padding in AES_WITH_PADDING mode
Why do you make this conclusion?
Actually, in AES_WITH_PADDING mode we should add 2 more *BLOCK*: for IV and
for padding info.
You can find sanity check in KeystoreEncryptionSpiSelfTest.
Please, take a look into KeystoreEncryptionSpiSelfTest#testEncryptDecrypt
which check the case you described.
чт, 31 янв. 2019 г. в 17:08, Максим Степачёв <ma...@gmail.com>:
>
> Nikolay,
> I see. We should close IGNITE-11129 as invalid. I'm going to ask the
> reporter, what he means.
>
> > Please, explain, why do you think so?
> I answered to Dmitriy Pavlov with explaining.
>
> In short, your method encryptedSize(int dataSize) returns the *"*wrong
> result*"* when I call it with dataSize = 20.
> I suppose the AES algorithm work with blocks by 16 bytes for
> encryption data + 2 bytes for padding in AES_WITH_PADDING mode.
> The current implementation works for dataSize = 20: ( (20 / 16) + 2 ) *
> 16. " 20 / 16 = 1." , Are we lost one block for 4 bytes? Or is it fine?
>
>
>
>
>
>
> чт, 31 янв. 2019 г. в 16:15, Nikolay Izhikov <ni...@apache.org>:
>
> > Hello, Maxim.
> >
> > > IGNITE-11129
> >
> > Do we have reproducer for this ticket?
> > WalRecord will be encrypted only if record class
> > implements WalRecordCacheGroupAwarei.e it contains some cache data that
> > should be protected with encryption.
> > Please, look into private boolean needEncryption(WALRecord rec).
> > SwitchSegmentRecord does not implement WalRecordCacheGroupAware, so not
> > encryption would be applied for this types of records.
> >
> > I think we should close IGNITE-11129 as invalid.
> >
> > > Should we use this code:
> >
> > Please, explain, why do you think so?
> > Do you find some bug?
> > Can you send a reproducer?
> >
> > You can find details of encrypted data size calculation in AES algorithm
> > description.
> >
> > чт, 31 янв. 2019 г. в 15:24, Максим Степачёв <maksim.stepachev@gmail.com
>:
> >
> > > Dmitriy Pavlov,
> > >
> > > Your statement about page size is true. But our case about plainSize
of
> > > serialized record in bytes. This method calculates it:
> > plainSize(WALRecord
> > > record). For example, if you look in this method, you will see
> > > DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum
of: 4
> > +
> > > 8 + 2 + 4 + uRec.payload().length where a length is an arbitrary
number.
> > >
> > > чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov <dp...@apache.org>:
> > >
> > >> Hi Maxim, why do you think that data size can be divided to cipher
block
> > >> size with 0 remainder.
> > >>
> > >> I used to think that page size 4096 is always divisible by a usual
block
> > >> cipher block size, e.g 32, 16 or 8 bytes
> > >>
> > >> чт, 31 янв. 2019 г. в 13:11, Максим Степачёв <
> > maksim.stepachev@gmail.com
> > >> >:
> > >>
> > >> > Hi, I have been trying to solve a problem with calculation size for
> > >> > encryption mode, it's ticket IGNITE-11129. But I found an
additional
> > >> place
> > >> > for wrong behavior. I'm confused, Is it fine or wrong? Look at
> > >> > *KeystoreEncryptionSpi#encryptedSize*, the result calculation
works as
> > >> >
> > >> > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
> > >> >
> > >> > But we don't have a guarantee that dataSize is multiple of
BLOCK_SZ.
> > >> > Should we use this code:
> > >> >
> > >> > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
> > >> >
> > >> > If yes, I'll fix it.
> > >> >
> > >>
> > >
> >
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Posted by Максим Степачёв <ma...@gmail.com>.
Nikolay,
I see. We should close IGNITE-11129 as invalid. I'm going to ask the
reporter, what he means.
> Please, explain, why do you think so?
I answered to Dmitriy Pavlov with explaining.
In short, your method encryptedSize(int dataSize) returns the *"*wrong
result*"* when I call it with dataSize = 20.
I suppose the AES algorithm work with blocks by 16 bytes for
encryption data + 2 bytes for padding in AES_WITH_PADDING mode.
The current implementation works for dataSize = 20: ( (20 / 16) + 2 ) *
16. " 20 / 16 = 1." , Are we lost one block for 4 bytes? Or is it fine?
чт, 31 янв. 2019 г. в 16:15, Nikolay Izhikov <ni...@apache.org>:
> Hello, Maxim.
>
> > IGNITE-11129
>
> Do we have reproducer for this ticket?
> WalRecord will be encrypted only if record class
> implements WalRecordCacheGroupAwarei.e it contains some cache data that
> should be protected with encryption.
> Please, look into private boolean needEncryption(WALRecord rec).
> SwitchSegmentRecord does not implement WalRecordCacheGroupAware, so not
> encryption would be applied for this types of records.
>
> I think we should close IGNITE-11129 as invalid.
>
> > Should we use this code:
>
> Please, explain, why do you think so?
> Do you find some bug?
> Can you send a reproducer?
>
> You can find details of encrypted data size calculation in AES algorithm
> description.
>
> чт, 31 янв. 2019 г. в 15:24, Максим Степачёв <ma...@gmail.com>:
>
> > Dmitriy Pavlov,
> >
> > Your statement about page size is true. But our case about plainSize of
> > serialized record in bytes. This method calculates it:
> plainSize(WALRecord
> > record). For example, if you look in this method, you will see
> > DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum of: 4
> +
> > 8 + 2 + 4 + uRec.payload().length where a length is an arbitrary number.
> >
> > чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov <dp...@apache.org>:
> >
> >> Hi Maxim, why do you think that data size can be divided to cipher block
> >> size with 0 remainder.
> >>
> >> I used to think that page size 4096 is always divisible by a usual block
> >> cipher block size, e.g 32, 16 or 8 bytes
> >>
> >> чт, 31 янв. 2019 г. в 13:11, Максим Степачёв <
> maksim.stepachev@gmail.com
> >> >:
> >>
> >> > Hi, I have been trying to solve a problem with calculation size for
> >> > encryption mode, it's ticket IGNITE-11129. But I found an additional
> >> place
> >> > for wrong behavior. I'm confused, Is it fine or wrong? Look at
> >> > *KeystoreEncryptionSpi#encryptedSize*, the result calculation works as
> >> >
> >> > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
> >> >
> >> > But we don't have a guarantee that dataSize is multiple of BLOCK_SZ.
> >> > Should we use this code:
> >> >
> >> > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
> >> >
> >> > If yes, I'll fix it.
> >> >
> >>
> >
>
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Maxim.
> IGNITE-11129
Do we have reproducer for this ticket?
WalRecord will be encrypted only if record class
implements WalRecordCacheGroupAwarei.e it contains some cache data that
should be protected with encryption.
Please, look into private boolean needEncryption(WALRecord rec).
SwitchSegmentRecord does not implement WalRecordCacheGroupAware, so not
encryption would be applied for this types of records.
I think we should close IGNITE-11129 as invalid.
> Should we use this code:
Please, explain, why do you think so?
Do you find some bug?
Can you send a reproducer?
You can find details of encrypted data size calculation in AES algorithm
description.
чт, 31 янв. 2019 г. в 15:24, Максим Степачёв <ma...@gmail.com>:
> Dmitriy Pavlov,
>
> Your statement about page size is true. But our case about plainSize of
> serialized record in bytes. This method calculates it: plainSize(WALRecord
> record). For example, if you look in this method, you will see
> DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum of: 4 +
> 8 + 2 + 4 + uRec.payload().length where a length is an arbitrary number.
>
> чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov <dp...@apache.org>:
>
>> Hi Maxim, why do you think that data size can be divided to cipher block
>> size with 0 remainder.
>>
>> I used to think that page size 4096 is always divisible by a usual block
>> cipher block size, e.g 32, 16 or 8 bytes
>>
>> чт, 31 янв. 2019 г. в 13:11, Максим Степачёв <maksim.stepachev@gmail.com
>> >:
>>
>> > Hi, I have been trying to solve a problem with calculation size for
>> > encryption mode, it's ticket IGNITE-11129. But I found an additional
>> place
>> > for wrong behavior. I'm confused, Is it fine or wrong? Look at
>> > *KeystoreEncryptionSpi#encryptedSize*, the result calculation works as
>> >
>> > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
>> >
>> > But we don't have a guarantee that dataSize is multiple of BLOCK_SZ.
>> > Should we use this code:
>> >
>> > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
>> >
>> > If yes, I'll fix it.
>> >
>>
>
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Posted by Максим Степачёв <ma...@gmail.com>.
Dmitriy Pavlov,
Your statement about page size is true. But our case about plainSize of
serialized record in bytes. This method calculates it: plainSize(WALRecord
record). For example, if you look in this method, you will see
DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum of: 4 +
8 + 2 + 4 + uRec.payload().length where a length is an arbitrary number.
чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov <dp...@apache.org>:
> Hi Maxim, why do you think that data size can be divided to cipher block
> size with 0 remainder.
>
> I used to think that page size 4096 is always divisible by a usual block
> cipher block size, e.g 32, 16 or 8 bytes
>
> чт, 31 янв. 2019 г. в 13:11, Максим Степачёв <ma...@gmail.com>:
>
> > Hi, I have been trying to solve a problem with calculation size for
> > encryption mode, it's ticket IGNITE-11129. But I found an additional
> place
> > for wrong behavior. I'm confused, Is it fine or wrong? Look at
> > *KeystoreEncryptionSpi#encryptedSize*, the result calculation works as
> >
> > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
> >
> > But we don't have a guarantee that dataSize is multiple of BLOCK_SZ.
> > Should we use this code:
> >
> > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
> >
> > If yes, I'll fix it.
> >
>
Re: Does KeystoreEncryptionSpi have problem with size calculation?
Posted by Dmitriy Pavlov <dp...@apache.org>.
Hi Maxim, why do you think that data size can be divided to cipher block
size with 0 remainder.
I used to think that page size 4096 is always divisible by a usual block
cipher block size, e.g 32, 16 or 8 bytes
чт, 31 янв. 2019 г. в 13:11, Максим Степачёв <ma...@gmail.com>:
> Hi, I have been trying to solve a problem with calculation size for
> encryption mode, it's ticket IGNITE-11129. But I found an additional place
> for wrong behavior. I'm confused, Is it fine or wrong? Look at
> *KeystoreEncryptionSpi#encryptedSize*, the result calculation works as
>
> (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
>
> But we don't have a guarantee that dataSize is multiple of BLOCK_SZ.
> Should we use this code:
>
> ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ;
>
> If yes, I'll fix it.
>